One of the neat things about Linux is that it will allow you to use hardware long beyond what you'd normally be able to use it If you ran something like Windows or Mac It wasn't too long ago when Windows 11 came out that we learned that Microsoft was going to Arbitrarily limit the amount of hardware that Windows would run on so if you ran something that was just two or three years old You may not be able to upgrade to Windows 11 now Since then they've walked that back a little bit and there's been workarounds and all this stuff But the point is is that Microsoft very often limits the amount what hardware their operating system will run on That's not something that ever really happens on Linux Even if certain support for certain hardware is pulled out of the kernel There are still distributions out there running kernels that will allow you to run Whatever you want there are still plenty of distributions out there that will support 32 bit and allow you to use Hardware that is 15 maybe even 20 years old and even beyond older hardware There are a lot of distributions out there that will allow you to run Linux on Systems that just have low amount of resources One of those distributions is Linux light and that's what we're going to be taking a look at today The most recent version of Linux late is version 5.8 now if you have never heard of Linux light before I Wouldn't be surprised because it's not a distribution that a lot of people have ever heard of it's Moderately popular I would say but it's not something that is in the mainstream It's not like a boon to or arch or something like that I have done a review on it before for the last major version and what I thought I'd do today is take a look at what's new And we'll run through a small installation of it so you can actually see what it is now like I said This is based on a boon to and it has several new features that are really cool So let's go ahead and jump in with Linux light 5.8 So this is the Linux light ISO in a virtual box now Before we jump into this too far Let me just say that I'm sorry about the big gigantic honking bars around this I can't get it to go full screen I'll mess around with the resolution here in a few minutes once we get it installed But I can't seem to get virtual box to go full screen and men jar. I don't know why it just is something that's going wrong But anyways, you don't care about that. Let's just go ahead and jump in So this is Linux light and we're gonna go ahead and first before we jump into the new features Go ahead and install it. So do this now. This appears to be the ubiquity installer So we'll go ahead and install this is the same install that you'll get if you just install vanilla boon to English is fine. That's the right keyboard layout We don't need to download updates. We'll do that afterwards and it will install a third-party stuff I usually do it that way and go ahead and continue and then install now and Then continue that's a proper time zone. So we'll go ahead and enter a username and that's fine And we'll enter a very complicated password and we'll go ahead and continue and it should start installing So I will cut the video here and we'll come back when it's done Okay, so that took about four minutes or so. Let's go ahead and hit the restart button We'll see if the ISO was removed from virtual box. Sometimes it is sometimes. It's not we'll see how that goes Looks like it's gonna load up just fine, which is good Okay, now that we've rebooted out of the ISO and into the Installed and installed distro. We can go ahead enter our password and then I'm gonna attempt to Change the display resolution. We'll see if this actually works We should be able to type in display which we can and then we'll see if we can find 1920 by 1080 here a few moments later and after some fiddling As you can see, this is as big as I was able to get it 1920 by 1080 wasn't an option So I can go through and install install guest additions and get the display working properly But it probably still wouldn't work because this virtual box hates me and everything I've ever stood for So I'm just gonna go ahead and move on I've wasted enough time trying to get that fixed. So let's talk about new features Actually before we do that, let's go ahead and quickly run through the welcome screens We got up install updates install drivers set restore point install language support and select darker light themes Let's go ahead and click on that because we want the dark theme. Okay, so apparently Interestingly enough the dark theme doesn't actually apply to the welcome screen, but that's not that big of a deal So let's see. Is there a way to go back? So this is just one long screen, but there is a home button up here Okay, that's good And I will go ahead and run updates So control alt T does bring up a terminal and we get a stylized bash prompt I believe this is back. So if we run neofetch And I happen to know the neofetch is actually installed. This is the bash shell. It's 5.17 We have a kernel of 5.4. So this is going to be based on Ubuntu LTS I believe if that's the kernel and this is Xfce. So this is a very lightweight desktop environment and Xfce has always been known for very low resource usage. Their theme that they've chosen is adapta So if you're familiar with manjaro, that's about the same theme that they use in all their distros as well So you'll expect something that looks really pretty. So I'm going to go ahead and run updates here So I'm going to pseudo apt update and and pseudo apt upgrade and enter a password So there are a few updates And we'll let that go and while that's running We'll go ahead and go back to the welcome screen So we have links for online support and other things like the help manual forums and so on and so forth We have ways of contributing and then we have the install button now. Here's the thing I booted into this and saw that that big install now thing was there And the thing is this I am installed like this is the actual Installed distro the ISO is no longer attached to virtual box. So it's installed on a hard drive yet They're still an install button So that's kind of annoying and kind of confusing because if you re log into Your system and you still see install now, you'll think well, did I install it or did I just imagine that four minutes And maybe I was delusional through the whole thing, but no I'm I'm installed. I checked So I don't know why the install buttons is still there. So we're going to go and click that and it close Now I'm wondering if the install thing is still here No, let's see if there's not like an install Linux light in the menu. So I don't know why that button was still there. So the the updates are installed now, which is good I'm going to go ahead and do a reboot here And then when we come back We will check and see for memory usage and stuff like that and then we'll run through the new features Okay, so we're going to open up a terminal And I'll zoom in a little bit. So if I do Unamed dash a we're going to see that kernel again, which is 5.4 and then we do free Dash m we'll get to see this is running at 528 megs out of the box Which is Very low compared to almost every other desktop environments in distro that you'll probably find out there now I've seen some run less But 500 is still really good. It's about half of what you'd expect from both kde and genom So this is very good for low end hardware Now that we've checked that let's go ahead and run through a few of the new features So we have an updated papyrus theme. So if we go through and take a look at the Applications here, you'll see that it now uses the papyrus Adapta a theme. I believe is what this is called. I don't know what these look like before but the papyrus theme has always been really good We also have several new wallpapers. So yeah, this was one of the new wallpapers And then this is one of the new wallpapers here And This is one of the new wallpapers here And uh, it doesn't I don't know what the other nine are but probably the rest of these around here as well well So that it has some really nice wallpapers They also have some linux light themed wallpapers that have the logo in them as well So those are probably the ones that used by default. So we can close that This is also the first version of linux light that comes in neofetch install. So we've already run this but I highly appreciate them installing by default because it means I don't have to go through and install it before I can show You guys the screen. So that's nice. Now We also apparently have a brand new widget and the interesting thing is that they don't enable it by default So usually when distros have conkeys, they've gone through and they just put it on the The desktop no matter what and you have to turn it off if you don't like it So we're just going to go ahead and enable that and this is what their conky looks like I'm going to go ahead and move My face out of the way so you can actually it's wrong button. Hello Anyways, this is what their linux light widget looks like this is based on conky. So it has cpu usage Total memory used logged in as your username firewall status disabled and then update status. So it says your system was recently updated I wish I had the actual date there when it was updated. That'd be cool But anyways, that is conky now like all conkeys. You can't actually move that around Easily sometimes there's a key binding to do it. I know mx linux has a Key binding to do it, but this doesn't appear to but you could always go through and Change the conky configuration file if you want to change the location of that as well Another thing that they've included in this release is something called mint stick Although if you search for mint stick in the menu, you won't get this At the top, it'll actually be at the bottom But basically what this is is a usb image writer So if you wanted to burn an iso to a usb stick This is going to be your tool that you'll have installed biddy fault If you don't want to install something like etcher or something like that So we can close this other minor tweaks include an updated help manual Which is which we can actually see here Yes, thank you firefox go away. Here we go So this is what their help manual looks like you can go through and learn pretty much everything you want to do Right here now one of the things I've always liked about linux late is that they do a fantastic job With documentation they always have and you can really tell that they are Pointing this towards new users and allowing them to Find out stuff on their own about their outbring system by creating a basic manual for them to use So that that's pretty much it in terms of actual new features So let's just go ahead and take a small look at all the applications that they have here Most of this stuff is going to be your run of the mill xfc style stuff The same kind of stuff that comes with pretty much every xfc and abutu based distro So we got genome disks. We have probably a graphical interface for ufw Font manual help manual a high dpi setting. So if you have a high dpi monitor, which is really nice to have that here We have a gimp installed by default Install drivers keyboard. Most of this stuff is going to be for xfc settings. So this is a light desktop It'll allow you to go through and enable enable or disable the icons here along the side And a lot of this stuff is going to be in the control panel as well So they're calling this the control panel. Usually if you're using xfc You're just going to see this called the settings manager or xfc settings It it does have all the linux light tools that they've developed So for example, the things we just saw like the light desktop We have the light info which which will usually give all the information about your Computer, but this is a virtual machine. So it's not going to actually work light network shares So i'm assuming this is probably Yep, this is samba. We can go ahead and quit that. I don't need to set that up But that's nice that that's there light software. This is going to be the software store So what is this actually? Would you like to update your software sources now? So that's probably running uh app update So we're going to install software And this is their little software Store now you can go through and install things like addacity and dropbox and all this stuff There is quite a bit here, but it's not the most extensive quote unquote store that you'll ever see It doesn't seem to limit itself to just open store software because we have chrome here as well So it looks like it's trying to hit the high points. So things like plan linux steam is here Skype is here spotify things like that the the most popular applications seem to be here including Microsoft edge so for those people who like edge could also install that So this isn't obviously all of the software that you can install You could pretty much install anything you want using apt or install something like snap or flat pack But if you want a GUI application for installing software, this is what you got So go ahead and go here and we can quit that and you can also apparently use that to remove software The they have the light user manager light upgrades going to be done for Upgrading packages like tweaks. I wonder what this is for. So this is a like a multi-purpose tool That will allow you to go through and run certain tasks. So for example, it will do a boot up feature Which I'd assume probably would run Something to help fix grub. There's a clear memory preference here. There's a clearing a whole bunch of different caches Yeah, there's a an option to remove old kernels an option to install a new kernel Changing the host name finding very large files save session Num lock and stuff like that. So this tool looks like it's for More advanced users most new users are probably never going to get into this But if you want something to go through and find an advanced tool to light tweaks Application looks like it's something that you'd be interested in doing So let's go ahead and quit there and it looks like you actually before we do that Looks like you can go through and select multiple things and you could do multiple of these tasks at a time that begin Let's quit that so That's linux light very quickly. It is a very good Linux distribution based on Ubuntu That is meant for lower-end computers or older computers that aren't they don't have a lot of resources to run And I like that about it. I don't think that it's flashy. It doesn't have a ton of tools. It has a few but it doesn't have a lot It they've done a good job of making it pretty so that you can because a lot of the distributions that are really meant for older And hardware are kind of ugly out of the box Like you can obviously go through and tweak them so they look better but in my opinion a lot of the older ones tend to Emulate windows 98 a lot of the time And it's not anything that looks all that great with this it looks really nice So if we actually go back to this just real quick Like we open up we didn't actually open up go through and open up any applications like this theme Is very nice looking. There's nothing to complain about here It looks very nice. And that's not something that is often something you can say about a distribution that is meant to run on low-end hardware A lot of the times those don't look all that great add on top of this that this is a boon to And it gives you an access to it a lot of software Also, it is based on the LTS. So you're going to go through and find that this is a very Stable distribution, which is something that most people who Run a boon to our boon to a boon to base distros really want So that is linux lite 5.8. It's one of those distributions that every time it comes out. I was like, oh, yeah, that's really good I'm glad that exists. It's not necessarily for me Because I don't really need a low resource distro But for those of you who do you should definitely check it out If you have comments on linux lite, you can leave those in the comments section below You can follow me on twitter at the linux cast You can support me on patreon at patreon.com slash linux cast Before I go I'd like to take a moment to thank my current patrons Cid a dev on patrick l primus marcus maglind jack snipe tool steve a separate linux eric Mitchell art center carbon did jeremy shawn odin martin e merrick camp drash li j dog peter a crucible dirt benethix and blad a Thanks everybody for watching. I'll see you next time


So hello, and good morning. Myself Sri Ram, I'm a senior architect at CalSoft. I have Swapnil, who is my co-presenter. He's an active contributor into OpenStack. Before we jump into the details, the nitty gritties, maybe I should speak about Bipin and Kashish. They are two dynamic young folks who have helped me with each and every re-edits, maybe 10 to 20 times that we had to do before we got this. OK. So we can quickly go through the agenda here. The agenda is plain and simple. The problem statement, essentially, what is that we are trying to address. Secondly, followed by proposed solution. This is an overview of what we are trying to propose, how it is going to make the changes. Then solution prerequisites. So solutions prerequisites are something like these are some set of changes that are kind of required, whether we choose any of the approaches following which are being discussed. Approach one is about client unaware striping. So essentially, you can say that the existing clients would be able to work as it is without any changes. But it would possibly have some kind of limitations, though. Approach two is a client aware striping, where even the client contributes into this effort. And this can make a much bigger impact. This is followed by possibly set of use cases. We have kind of five use cases which we have tried to put here from the real world, which are how to export object store as a volume. Second would be can we implement something like a redirect and write based snapshots, row snapshot kind of thing. Third is a CDP solution. Can it be built on this object store, which is having striping support? Fourth is a bit different thing. Something like trim or unmapped. In a typical storage world, especially this is used with a SAN environment or even with latest SSDs, that you have the trim or unmapped support. So how can that be brought into with striping, actually? And finally, can we build an object-based file system? So these are the five use cases that we are trying to think about. So you can possibly start relating it when we are discussing the approaches, actually. Following this, there are some enhancements in Future Scope. So one of them, which I can quickly mention, is about we are also trying to think, can something like erasure coding be used instead of the current multi-copy mirroring that is happening in Swift? And there are some more Future Scope things. Appendix is typically having something like the JSON headers, which for the HTTP request, that would be modified in this implementation. So it is more for the developers who would believe in this idea and would want to implement it. So it's just some kind of a guideline. Apart from that, there are C also. So C also has something kind of the rest of the papers which we are trying to work, which possibly didn't get selected, but would certainly be put on our website. So there are five more papers that we are trying to work on, actually, which should be available on CalSaf's website soon. Moving on. So the problem statement. So traditionally, an object store has been viewed as a store for smaller size objects. Having said that, Swift does support large objects. It does so.  And the means of doing it is like it does it by segmentation and via a manifest file. Typically, you must be aware of this. Like, manifest file is, you can say it is the root file to this large object, which is storing all the segment-related information. So essentially, you hit into the manifest file, get all the segments-related information. Where are they lying? And then it's folk to those particular segments. And that's how the get-and-put request would be executed. Limitations, obviously, for large objects are today like it's still costly in terms of time, the network bandwidth usage, or even the storage utilization, I'll say. Manifest file is limited by a number of segments. As the number of segments starts growing, it becomes really difficult to manage large objects and stuff. Well, I've been discussing a lot about large objects. But more important fact that we are trying to cover is varying size objects, be it a regular, small, medium object, or be it large objects. They are being treated separately or differently in Swift today. And that is what we would like to go away from, actually. If there are any questions in between, please feel to raise your hand and ask. That should be OK. I would prefer to have an interactive session. So proposed solution. So what is the proposed solution? So object striping is a technology. It's not a solution by itself, actually. So when it is blended with the sparse object or parallel reads and writes to multiple object servers and vector IO at the object server end, then this equation actually builds up a solution, which we are trying to look out for. So it can be treated as an equation, actually. So delving into the details, object striping is not much different than today's segmentation or chunking. But the most important thing is it is not confined to only large objects. So essentially, as the object size increases, you'll see more and more stripes. So you treat all the objects similarly. Well, this also helps in storing this object. Yeah. Fine. So speaking at this in comparison to erasure encoding, as you're working through this, can you make it kind of distinguish those areas of the panel which are proposing this looking at it or addressing it in a different way? So erasure coding, certainly we haven't thought in this process. But when we went in quite a details about this, we realized that erasure coding is something that can be certainly added. But that, in case it would be more of a problem, we are trying to solve at a larger scale. Essentially, the replication part of whatever proxy tries to do, like whatever our replica number is stuff. So those all stuff would be totally removed, the multi-copy mirroring. But that is not exactly what we are trying to solve here, at least in this paper as such. Here, we are trying to solve maybe a better way of segmentation, better handling of objects. And based on that, what all can be achieved, actually. Does that answer? Yeah. So yeah, going ahead like, yeah. So I was trying to say that object striping, actually, will also enable the object to be spanned across multiple object servers. So we'll see how exactly in just a couple of minutes. Sparse objects. Now, sparse object is something like, essentially, not all the stripes need to be consumed. When I say that it's a sparse object, you just say that it's a 1 GB object, but possibly have just stood a single stripe in it at an offset of maybe 1 GB. So essentially, the disk space consumption, if you're considering, it's just 1 MB. But object size, it's possibly 1 GB. So virtually, you can say that we are also getting away with the limitation of object size, essentially. So you can write to any offset of an object, and it should be done kind of things. Following this, parallel reads and writes. So essentially, here, what we are trying to do is, since the stripes are going to be pushed into multiple partitions and so, essentially, into multiple object servers, the read and write operations are going to involve multiple object servers. So in literal sense, we can get parallelism, because object servers are completely different entities to which you can send the request. You read all the stripes in parallel from all the object servers that are involved. But here, also, we have to be really optimal. We can't just say that we'll try to use maximum number of them. But it should still be an optimal maximum number. It can't be too huge. So that is what we're trying to put here. Following this, like, vector IO. So here, the way to look at this complete object or its life cycle or what to say. It's topology, you can say. So a single object, you can say that it is divided into set of sub-objects. These sub-objects go into maybe unique partitions. And so the term sub-object has been introduced already. So it is nothing but a object or a smaller size object, which is holding one or more number of stripes, but not certainly all the stripes. So here, essentially, what we are trying to do is the sub-object itself will be something like a sparse file or a sparse object by itself. So suppose that there are just two stripes to be written to a particular sub-object, then they would be written to that particular offset. So being a sparse file kind of an implementation, it is not going to consume any extra space for the holes that are going to be created, actually. It is just going to write to those particular offsets. And that is the maximum space that is going to be consumed. So considering this, Vector.io is something that really makes sense, because we might want to write or read multiple stripes from a single sub-object on every partition or every object server. So Vector.io is something that we are trying to propose, which should be used to do the required IO, actually, at the object server end. So essentially, looking at the advantages that can be gained, it's like the maximum number of object servers being involved in read and writes, increase in shifts throughput, then load sharing across multiple object servers. Because when we were trying to do a bit of experimentation with this, we found that even with the existing hashing functionality, the stripes were getting very much evenly distributed across partitions and hence across the object servers. So being an even distribution or at least moving towards even distribution of stripes, the storage consumption on every partition and hence object server is evenly done. This not only helps with the parallel reads and writes, but possibly can help us with rebalancing also. When a new object server node is being added or removed, we move the partitions. And now most of the partitions being consumed evenly, it would really make sense. And the rebalancing effort would be helped a lot, actually. Next advantage could be the object size has no limitation now. You can go to whatever size, be it 10 GB, 100 GB, whatever size you want. It's just the offset that at which the stripe is going to be written. And most importantly, not all the objects, be it a small object, be it a large object, is going to be treated in a similar way or fashion. Any questions about this? So this is a quick glossary. We already introduced the sub-object term, but here it is mentioned. Portion of an object consisting of one or more stripes stored sparsely in a partition, or a partition file, I'll say. There are other terms. We have added a term of stripe ID, a unique identifier from stripe within an object. Stripe size is something that is just to be defined and stored in the objects or the container database more for as the striping information. Container DBs. So this is a change in the database schema that we are trying to propose. Object ID does exist. Stripe size is something that we want to add to it. Object size is what we would like to add. Object on this size, so on this size would be more for what is the actual consumption of the storage is what can be very well known. Object version delta size, so this term will be very much used when we discuss about the use case about snapshotting over object servers or object stores and also a CDP kind of solution, a continuous data protection solution. So essentially, there are some thumb rules that we would like to follow. Different objects may have different stripe sizes. But for a given object, the stripe size remains same. So once it is decided, then it becomes immutable. So I mean, these are thought in a way that we don't want to make drastic changes in Swift because then adopting to it would be really difficult. So we are trying to put certain set of limitations in our approach also. So here are some formulas actually. So what is a stripe ID? A stripe ID can be simply said to be the numbering. But we have tried to define it more as a function, a function of stripe offset, stripe size, object path, and partition. Now possibly, stripe size and offset is very much understood by everyone. The reason we are trying to add this optional parameters of object path and partition size is if you want to implement a better function by which you can even distribute the stripes. You can make better decisions based on the object path and the partition size also. Similarly, there is another function, which is stripe offset, which can be calculated from stripe ID, stripe size, object path, and partition size. So the relationship between these two functions is like they are inverse to each other. So if you have stripe ID, you'll be able to find the stripe offset. If you have stripe offset, you'll be able to find the stripe ID. And that's how these functions need to be defined. So one more thing, like yeah. So essentially, the stripe ID is never, what to say, stored as such. There's no database entry that you have seen here that we have tried to put. So it is something that can be always calculated by any of the entities, actually. So role of this stripe ID hash. So object ID, we know about what it is. Stripe ID hash is nothing but this will be a new URL that we'll try to form. And its hash would be something as stripe ID hash. So we are appending a stripe ID to it. So the salient points here can be like today object ID is being used to determining the partition. It won't be anymore. Stripe ID hash would instead be used, actually, to decide the partitions. And so essentially, partition is now a set of stripe ID hashes and not, what to say, of the object IDs, actually. The advantages, possibly we have discussed this, even distribution, optimal multiple object servers participation, and ring rebalancing. The extended attributes, essentially, today they look in this fashion. We are saying that from object-based extended attributes move to the stripe-based extended attributes. So there's a stripe ID that is being added. And possibly the rest of the things pretty much remain same, but they are with respect to a stripe ID. Essentially, you'll have multiple set of extended attributes because a single sub-object could hold multiple stripes. So this is a basic change in the HTTP request that we are trying to propose here. So this is with respect to a communication between a put request from the proxy to the object server. So this is a new header that we want to really add, which holds the object ID, stripe ID, stripe size, HTTP request offset. So this is actually the data of the stripes that are coming in, which are needed to be sent to an object server. And so all the fields determine to enable the object server to get the required information, be it stripe content length, object size, and stuff. So here, we can note actually that there are multiple objects to which a single HTTP request is being sent. So this will see how it makes sense in the approaches when we discuss them. The response would be something as follows. Like from the object server, for every stripe that has been written, it sends back and state is saying that was it a new write, was it an update, was it a trimmed value? Trimmed here means we are deallocating the stripe. So here, you can see the stripe delta size that is being discussed out. So essentially, whenever there is a new write, there's a change in the size. So that has been mentioned out here. When it is just an update of an existing stripe, then possibly there is no change in the disk space that is being utilized. So it's zero. And trimmed is like you're actually removing the stripe. So essentially, when this response is received by the proxy again, it can just simply add all these values and determine what's the actual object on this size change. And just collect all the HTTP requests coming from all the object servers involved for a particular object. And it should be able to just add all those and update the container database with the respective on this size. So and similarly, stripe max offset is something that can be used to determine the object size actually. So these functions have been defined out in a simple form actually. It's a max of so and so things actually. Moving to the get request, pretty much similar lines. You can see the request sends the stripe size, stripe content length, whatever is the ID, and the object offsets. On the object server side, based on the stripe ID, it identifies the offset and gets the stripes, builds this HTTP request, and sends it all together. So here also, we can see that a collated request of multiple objects and stripes is sent to a single object server. So it's like we're trying to piggyback multiple stripe to read requests in a single HTTP request. Moving on, there are some miscellaneous changes. So fingerprinting would be used at the stripe level. Essentially, it is for in a case where the same stripe has been sent over with no changes, object server just calculates the fingerprint for that particular stripe, compare it with the fingerprint that is stored in the extended attributes. If it is the same possible, it doesn't need to do any IO and just say a success. With regards to replicator, auditor, and updater, here they will have to now work based on stripes, not on objects. So essentially, whenever an auditor has to check the fingerprints from the hash table, it will go to check the stripes fingerprint rather than an object's fingerprint. So essentially, they have to work at a granularity of a stripe and rather not at a object. So yes, we're coming to approach one. So there are these two approaches. One is a client unaware striping and the other one would be client aware striping. So client unaware striping, if you have to see here, is the proxy is actually going to be involved in striping the objects and collating even the request. So this is totally going to be transparent to the client. The client just sends as today the objects. It gets striped on the proxy and then it's sent or collated and then sent to the destined object servers. The proxy is the one who is essentially going to calculate the stripe ID hash and determine the partitions and hence the object servers. Collation, so here what we are trying to do is just to optimize things. Not only request for a single object are sent to the object servers, but the requests which are coming from maybe multiple objects, multiple clients for multiple objects, the stripes from each of this object which are destined for the same object server, they are collated into a single HTTP request and then sent down to the object server. So essentially that has to have some collation criteria and we have defined the simplest way. It could be either time out based or it could be size based. A typical SLA, there's nothing different. So in this approach, yeah, approach one, the stripe size is going to be the same actually for all the objects. The reason being like typically how does, how to determine the stripe size. The stripe sizes typically would be a function of something like what is your network bandwidth that is available? And maybe other processing powers and other stuff. But here, since the striping happens at the proxy and is just sent down to the object server, so you're still in your private network and you know exactly what is the network bandwidth and possibility is going to be same across. So there's no point in having different stripe sizes for different objects because it's not going, it's just going to complicate the things. So here, all the objects would be striped at the same size. This is for approach one. So typically how would the put operation work? The request comes as a complete object to the proxy. The proxy stripes it, proxy decides the partition based on the stripe ID and the calculation that it is going to do. It even collates a request from multiple clients for multiple object server, objects. HTTP request for, so it's already, it's sent in parallel to all the object servers. These sub-objects essentially are returned by the object servers using vector IO and the response is sent back. So we're just trying to put all the rings, the swift proxy and the clients and you can see the stripes of various different objects. So S one is a stripe of first object, S two is a fourth and kind of things. Moving on, so this is how a typical HTTP request would look with regards to the proxy being, the request coming from proxy to the object server and the response coming from the object server back to the proxy. So it's a typical scenario where we are trying to put like client one is trying to write object one and client two is writing object two. So how they get collated and how they are sent down to single object server and how the response comes back actually. So similarly on similar lines, it's for the get request. So here multiple requests coming from various clients are again converted into stripes forwarded to the object servers. When the response comes back from the object servers using vector IO read, it will just collate all those things and send it back to the client. In this process also, well, that's for approach too. Okay, so essentially here the overhead is kind of assembling the object again and then sending it back to the clients actually. So this is just explaining the scenario with regards to the objects actually. The HTTP request, how they are going to look and how it is going to be formed. So what are the pros and cons or any other miscellaneous changes? The pros are like modifications are confined to the Swift server, client is not involved at all. This is an increase in effectiveness of vector IO at the object server as proxy collates the request from multiple clients actually. Since it's trying to collate all the requests coming from various clients and sending it down to the object server, it just is good for vector IO actually. So the performance can be much better. Well, the cons, possibly even today it applies, proxy can be a bottleneck out here in this approach. Collation of stripes of objects from multiple clients leads to synchronization issues. The collation criteria that we have tried to mention which is SLA-based, time out-based or size-based that is certainly going to have an impact on synchronization actually. Well, miscellaneous changes. So essentially the changes are in the Swift container server, proxy and object server. And typically like replication auditor and updater have to work at stripe level. So moving on to approach two. So here what we are trying to suggest is like if the client can be really involved in the striping effort then there's a much more benefit actually. So striping or not really striping as such but Swift client when being used by the applications above it if they send down the request for maybe just taking the use case of building a volume over an object server or an object store. So essentially consider like couple of objects or few number of objects, large objects are collated to form a volume at the client side. And in that case, IOs are happening on a particular volume by any application at a random offset. So based on that actually if that request is directly sent down to the Swift client it would be able to determine that okay. So it is at so and so offset. So it is possibly I can say is part of a particular stripe. So I just need to send that particular stripe as a put request to the object server and that should be it. So essentially what we are trying to say is the Swift client is now capable of taking the request at a stripe level from the applications which are using the Swift client and passing it on over. And similarly this can apply for the read operations at the volume which is being built over it. In this what we are suggesting is also like we can piggyback the information of the striping in the get request put obviously we'll have it but get also we'll try to piggyback. The only the thing that we are trying to consider is like if there are any updates on the object which are not known to the particular Swift client it can get notified via the get response itself. Well there is some amount of metadata cache the client will have to store which would be something similar to what we discussed in the container DB changes. Stripe ID being a function now can also be calculated by the Swift client. Well stripe size of an object. Now here the stripe size can be determined during the very first put of an object. And so it can be a function of the network bandwidth and other stuff based on whatever client sees. So here it is like now we are trying to have an optimization starting from the client end to proxy and from proxy to the object server. So everything the network bandwidth is being used very optimally across end to end actually. So here the client can determine based on its own network bandwidth that okay now I want just maybe a half MB of a stripe size because that's what would suit me better. In other cases it could be one MB. So it depends on the client and its own parameters that what it is the stripe size would suit itself. So it's an optimization which the client itself can do. I mean this is going to complicate the Swift, not really the Swift client but the application that are trying to use the Swift client. But it's at what to say, it's at the optimization that you're going to gain out of it. So the put request. So essentially whenever an application sends a request of that so and so offset of data or data is being changed in this particular object, the stripe is built out of it. So it could be like some plus and plus minus amount of data that the Swift client will have to pick and then start sending it down to or send it to the object servers. So here the use cases that we have tried to discuss in that it's very much possible that the application itself is trying to do something like an vector IO on this volume that is built over the objects. So the Swift client could get multiple read or write requests essentially which are get or put request from Swift's perspective. And these all requests can be then collated and sent out to the proxy actually. So essentially it's like striping is happening out here sending it to the proxy. The request are then sent down to various object servers and they give back the responses and respective clients are given the required set of stripes. It's not the complete object ever. It's always going to be in terms of stripes now. Well this is a scenario where Swift clients want to write or modify some stripes of object one and object two. So here the stripe size we have just taken for an illustration of one zero two four and so one KB and one and half KB. So Swift client forms a single request and clubs information of modified data of stripes in it and sends a write or a put request actually. So this is the put request that would come from client to the proxy. Proxy based on the stripe ID identifies the object servers as was even in the approach one and then sends it to the respective object servers. So S2 for object one and S1, S3 of object two reside on the same object. So all these three stripes would be sent to the same object server. This is how the response would look like. This being a put request of all new writes kind of sake. So the response from object server to proxy is going to be the status as new write, stripe delta size is going to be an addition and when this information is received by a proxy, proxy is going to send back pretty much similarly a response to the clients. So here in this second approach, I would say that proxy is acting more or less like a pass through actually. It's not trying to do heavy or it's not doing any heavy lifting actually. Whatever heavy lifting is being done is mostly at the client end. So essentially the processing and stuff we have pushed it to the clients and we are utilizing more and more resources actually rather than all the load coming to Swift itself. It's the clients also doing some amount of processing. Well, on similar lines, the get request, the whatever are the stripes that are requested by the application to the Swift client, those as get request in a collated form are sent to the proxy. Then proxy actually identifies where these stripes have to be read from essentially the partitions and hence the object servers. Gets all or fetches all of them from the object servers, collates it together and rather here, another benefit is like the proxy is not going to assemble all these stripes. So whatever order it receives from the multiple object servers, it can just club it together and send it back. In earlier approach, if we see, we had to actually assemble the stripes because the clients are not yet aware of striping and stuff. So the proxy has to have a complete object so it has to be assembled together. But here, that's not the case. Even the client is aware of the striping so you can just send it in whatever order you received it. And client is efficient or knowledgeable enough to take the decisions. So here, this is just a, what to say, an illustration of how the HTTP request would look like. These are special headers. These are not part of the existing HTTP. So these are the headers that we are adding. Well, I think we can skip this. This is the response. So here, we can see actually that the piggybacked information in the get response actually. So here, we are trying to say that the object size has been changed which possibly you were not aware of and you can update your metadata cache at the client. So it helps in its further striping and other stuff actually. Well, pros of this, like proxy is offloaded from striping and collation tasks. It's no more its task. It's a task of the client itself. Or rather not even the clients because applications that are using Swift Client are anyways going to do kind of vector IO or multiple offset IO's. So essentially, this has been offloaded in this approach. Then we are utilizing more of the client resources than at the Swift server resources. Reducing network bandwidth usage from client end to the object server end actually. So it's not just limited to the Swift server. So it's much more optimal from network usage. Cons are like proxy still has to assemble all the stripes coming from multiple object servers. So as we know that since the sub-objects could reside on multiple objects, the reads are going to be parallelly done. But at least it has to wait till all the reads are done from the object server. Maybe we can think of this as an optimization where it could be sent down whatever stripes have been red can be sent down back to the Swift client and just say that wait for another set of stripes that are coming. We are not yet done kind of things. So this con can still be removed. Well, miscellaneous changes. Actually, we are touching possibly all the components of Swift in a limited fashion. Our applicator, auditor and updater have to work on stripe basis and not at the object. So we're kind of done with the two approaches. We'll move into use cases if there are any questions on the approaches. Yeah, sure. Okay, projects on GitHub that does striping entirely on the client side with no server support at all. And it's horribly slow because all of the writes, they do come from different object servers. And all of the writes go through one container server because the objects get abducted. The container server is still a lot like. How many are sold in there? So essentially if you have seen the container database changes, we have kept it really minimal. There's no striping information that we are storing at all or stripe information, I'll say. We are just storing basic striping information. By striping information and stripe information, how I would like to distinguish is striping information is the information required to do striping. And stripe information is like every stripes information has been kept out there. So, and that's why it was very important that we had to define stripe ID as a function and not as a database value. And the stripe ID is not a database value. It is a function. And that would make a big difference. You don't need to go to the container. Right, right, right, right, right. Any other questions? Yeah. Your solution is to enable both of these cases or are you suggesting that they choose one or the other? Well, we would recommend approach two, but it would be something like a bigger change. So, well, yes. Certainly this can be done. There's nothing that is going to stop it. And based on the, maybe we can see that the client, based on the client versions, we can just decide whether proxy has to be involved in the striping or not. And just, right, right, right, right. Exactly, yeah. Any other questions? Yeah. Sorry. I'm just wondering if you modify a single stripe. I mean, stripe number five, let's say. How you deal then with generating ETAG for whole object if I just want to do a head? So if I understand the question, right, you're saying multiple clients are updating? No, no. So I have my object, right, and it's built from 10 stripes. Okay. And then, as far as I understand, I can modify one of those stripes. Yes, you can, yeah. So I'll modify stripe number four. Okay. So I just want to get a head for the whole object which contain ETAG, which is basically MD5 sum for the whole object, right? So how you deal in that case? Because you need to regenerate ETAG, right? If I modify the single stripe. So, we are not really storing the fingerprint at an object level. We are saying the fingerprint will be stored only at stripe level. Right, but still if I just do a list. Right. If I just doing list, I'm just getting information that my hash is very specific, right? Right, so if I just do a list for the object which contains all the stripes, it should contain the proper MD5 sum. Otherwise, if I just do a list and then I just get get get, then my validation of the MD5 sum will be incorrect. Right. So, essentially, if we are going by approach two, then possibly even the client is not really requiring any object level MD5 sum. Yes, Barthich is unaware about that. Right, in that case, possibly what we'll have to do is something like an incremental hash function would have to be implemented. Fine, following these are just the use cases. I'll just like take a minute or so. So, because now striping and collision is supported, it can be used as a volume or object storage can be used as volume. So, that is first use case. Second is like, so we were thinking also like once that is done, possibly we can have it put over a SCSI target. The Swift client is coming to a SCSI target and that SCSI target is now exposing those volumes as over various fabrics like I SCSI, FCE, FCOE, anything. So, essentially, it can be extended to that level too. Yeah, I mean, the striping certainly helps build, or with striping we can certainly help build it. Possibly I'm not getting your question. Yeah, maybe. So, the presentation would be available on the URL, possibly which will be published. If there are any questions, you can certainly mail me on my official ID, shriram.poray at calsofftinec.com. So, just the use cases, redirect on write snapshot can be implemented. Morad, continuous data protection can be implemented. And there is something called a trim or unmapped that can be really supported. So, this you'll find our relevance with SSDs today. And finally, something like an object-based file system. So, maybe you can read through this presentation and if you have any questions offline or otherwise over mail, I'll be more than happy to answer them. Thanks.


At Audiology Associates of Prestonsburg, you can live your life the way you want and find the freedom of better hearing. With 40 years of being in the hearing care industry, you'll experience patient care that is specific to you with exceptional follow-up care that ensures your hearing and balance needs are being met. Audiology Associates at 1428 Northlake Drive in Prestonsburg. May is Mental Health Awareness Month and according to the CDC, over 50% of Americans will be diagnosed with a mental illness at some point in their lifetime. We spoke to Cheryl Combs, a clinical social worker, on the importance of mental health and resources in the region. I think it's important to talk about what mental health is. The definition of mental health is something that's kind of difficult even for mental health providers to be able to come to an agreement on. And so the one that I adopt is the one that assumes that mental health is a state of well-being that allows individuals to cope with the normal stresses of life and function productively across several domains. So the importance of maintaining good mental health is that basically mental health is the foundation of everything that we do in life that matters. It's the foundational skills necessary to be able to have good physical health because that involves our thought processes, our beliefs, our behaviors around good mental health, around social skills and social interactions. Healthy relationships involve that same structure of thoughts, feelings, behaving in a way that promotes healthy social interaction and supports healthy interconnected relationships. Big Sandy Healthcare has two clinics in Pike County in addition to clinics in Floyd, McGuffin and Martin Counties. They also have access to telehealth services through the University of Kentucky. There are a few suggestions that I like to discuss with people to empower them to be able to identify the best service possible to match their specific name. Because it's important to understand that there's no one-size-fits-all therapist which means one therapist isn't going to work for all people or all concerns. It's important to arm ourselves with the understanding of what our specific concerns are and be willing to ask questions to that therapist or to that mental health provider because it is a service that's being provided to you. So what that means is that it's helpful to consider an interview on both parts that not only are they interviewing you but you're interviewing them to see if this is a good fit because we want to be able to click with that person. And so for me to find the right mental health provider, that's going to mean that I'm going to find someone who I feel like basically gets me and understands the gist of what my concerns are. And that's a basic foundation of being able to build the trust and safety necessary within a therapy who's setting to be able to receive the kind of help that we need. For more information or to schedule an appointment, call Big Sandy Health Care at<PHONE_NUMBER>. Reporting for Mountain Top News, I'm Brianna Robinson.


This evening, it is my distinct pleasure to introduce Ronald Hamoui. Dr. Hamoui is a professor emeritus of intellectual history at the University of Alberta and previously was the assistant director of the History of Western Civilization program at Stanford University. He is currently a fellow in social thought at the Cato Institute and is the author of books on the Scottish Enlightenment, Health Care, and Drug Prohibition. He is the editor of the Encyclopedia of Libertarianism and of Cato's Letters. He's also a close friend or was a close friend of Murray Rothbard and was a student of Mises in his seminar. So without further ado, it's my pleasure to introduce Ronald Hamoui. Thank you all for coming here. Is this, am I loud enough? The topic that I wish to discuss this evening is the Canadian health care system about which much has been rooted about. Unfortunately, most of the comments are ignorant of the actual conditions of those that persist in Canada. So I thought I would give you an outline of actually how it functions and what it does. Now we're all familiar with the problems. We're all familiar with the problems that are endemic to the current health care system in the United States and its intolerably high costs, which if allowed to continue will within the foreseeable future, bankrupt the nation. To give you some perspective, in 1960, aggregate spending on health care in the United States was approximately $27 billion or $143 per capita. By 19, by 2003, this amount had increased to $1,679 billion or $5,560 per capita. And even in constant $2,003 per capita spending has increased over those years from $891 to $5,560. By 19, by 2009, I'm old enough to keep making this mistake of saying 1900. By 2009, total expenditures on medical care in the United States had reached $2.5 trillion or 17.6% of GDP. And these are projected to reach $4.6 trillion in 2019. And of this total, more than 51% are government expenditure. Obviously, this rate of growth cannot continue, but politicians seem unwilling to either abandon or cut back the programs that lie at the root of this prodigious increase. In place of the system now that exists in the United States, increasingly large numbers of Americans have suggested that the US adopt the same health care system as currently prevails in Canada. They point to the fact that all Canadians living in a country that in most respects is similar to the United States are insured for all aspects of their medical care, except drugs, and that Canada appears to manage this siege while expending slightly less than 10% of their GDP. They've managed this through a national health care insurance scheme administered by each of the provinces and based on a fee-for-service payment to physicians and annual block grants to hospitals and medical centers. The result is that the Canadian system provides medical services similar to those that exist in the US at about half the cost. As attractive as this alternative sounds, however, it's based on ignorance of the actual conditions that prevail in Canada, and it is worthwhile to take a look at what really goes on there. Let me just make a couple of mentions of the historical background to the current Canadian health care system. Canada, of course, is just one of a large number of countries that have instituted a state-run health insurance scheme. The first of these was instituted in Germany. In 1883, enacted by Chancellor Otto von Bismarck, the newly elected chancellor of United Germany, who gained passage of a whole series of socialist measures, the main aim of which was to pull voters away from the then liberal opposition. And in this, he proved completely successful. Intellectuals and social democrats throughout Europe looked on Bismarck's attempts to forge a powerful centralized state through the enactment of social legislation with great favor and were soon successful in introducing similar measures throughout the continent. Compulsory health insurance, particularly, was hailed as a model of regressive legislation and was emulated by a number of countries, including, of course, Great Britain, who in 1911 instituted the National Health Care Act. Now, in Canada, the introduction of a government health insurance system can be credited to Tommy Douglas, a Baptist minister and socialist politician who led his party, the Saskatchewan Cooperative Commonwealth Federation, to victory in the provincial elections of 1944. As premier of Saskatchewan, he'd immediately institute a whole series of socialist measures, the most important of which was a proposal to nationalize the medical system in the provinces. It called for all physicians to become salaried employees of the province and all hospitals to be situated in designated sites and run as government bureaus. Needless to say, doctors were strongly opposed to this and, in fact, went on strike, but they were forced to settle for, Douglas was forced to settle for a compromise set of acts that allowed for free hospital care to most Saskatchewan residents. The Saskatchewan plan was soon emulated by other provinces and its popularity adopted by the federal government. In 1957, the Ottawa government, under Prime Minister John Diefenbecker, a conservative, enacted legislation that provided that the federal government would underwrite 50% of the costs of hospital programs throughout the country. Finally, in 1966, under pressure from the New Democratic Party, which was the successor name of Tommy Douglas's cooperative Commonwealth, passed the Medical Care Act, which extended the existing program to cover physicians' charges. So both hospitalization and physicians' charges were then covered by a government program. Now, I personally have always found Tommy Douglas, a particularly repellent figure. He was ignorant, stubborn, sanctimonious in due part to partly to the fact that, of course, he himself was a minister. This reaction to Douglas was intensified by the fact that he is particularly beloved by almost all Canadians. Canadian historians have a penchant for turning their major figures into saints, and he's regularly hailed as the most outstanding figure in Canadian history. Indeed, in a CBC poll conducted in 2004, he was voted the greatest Canadian ever, which is possible he might have moved. However, a lesson, however, a less enthusiastic examination of Douglas's background shows someone less. His MA thesis, written in 1933, dealt with the need for a national eugenic policy that would weed out the unfit and ensure that only those meeting approved standards were allowed to procreate. Among the suggestions Douglas put forward was that couples wishing to marry would first have to be certified as morally and psychologically fit by the state. Should it be determined that either prospective parent was intellectually deficient or incurably ill, they were to be summarily sterilized. Those who were regarded as only morally deficient would be sent to concentration camps, which Douglas called state farms. It is not unlikely that Douglas's proposal led to Saskatchewan enacting a sterilization statute in 1933, the same year that Hitler came to power in Germany. Douglas was an inveterate proponent of war government. He enacted a number of laws extending provincial control over the economy during his premiership of Saskatchewan from 1944 to 1960. And during that period he nationalized electric power and telephone systems in the province, instituted a system of government automobile insurance, nationalized the bus service within the province and so on. For those of you who go to Saskatchewan, you will appreciate his reforms. The introduction of Medicare in the province was not without difficulty. When Saskatchewan instituted a universal medical Medicare program in 1962, doctors were so upset that they called a strike, which lasted in closing their offices for 23 days. Now it is in fact the case that the mortality rate dropped during this 23 day period, but they were finally persuaded to return to medical practice because the provincial government very cleverly raised the fees that they were prepared to pay doctors so that doctors now saw an opportunity to make windfall profits by taking advantage of the government. The Saskatchewan model was made national by Lester Pearson in 1966 and was exceedingly well received by the Canadian public. Let me give you the main provisions of the act are that all hospital and doctor fees will be administered by a government entity, that all medical services and hospital services are to be included under the act. The same level of service must be provided to all those who are insured, that the coverage that a person receives in his province is extended if he travels outside that province. With respect to coverage outside of Canada, the coverage often borders on black humor. Several years ago, for example, Alberta, which is the province in which I lived, allowed 50 Canadian dollars a day for hospital coverage outside of Canada. And this was at a time when Canadian dollars worth 62 cents. I remember being hospitalized and receiving my $36 a day to cover the costs. In addition and most important, the various provincial plans are prohibited from extra billing for any insured service and for levying any user charges. There are no deductibles, no co-payments for any service covered under the act. Canadian Medicare remains one of the nation's most popular programs. And in fact, in a poll in 2009, those surveyed showed overwhelming support for the Canadian system over that in the United States. And in fact, on the surface, there appears to be every reason to share its popularity. After all, the Canadian system seems to offer medical and hospital services, somewhat comparable to those in the United States where all the residents of Canada aren't sure, as opposed to just 85% in the West. And where the costs of running the program are about one third less than they are here. This, however, is a very superficial reading of what really goes on there. Most obvious difference between Canada and the United States in terms of medical service offered is that it is true that all Canadians are insured for the full amount of medical services, but they have to wait in line to get these services. Since it is illegal to charge patients to reduce demand, that is the cost of medical service or hospital services effectively zero, the only available method of rationing use is by queuing with all of the inefficiencies associated with non-price rationing of scarce resources. The result is often long waits, both to see specialists and to undergo treatment, to give you some idea of how onerous these wait times can be. The median wait time between original referral by a GP to treatment of a condition in 2010 was 18.2 weeks. This wait time varied by specialty and by province, but were always consistently substantial. The longest wait time, for instance, was for orthopedic surgery at 36.7 weeks. Medium wait time for all specialties from referral by a GP to a specialist in New Brunswick, one of the provinces where New Brunswick was the worst offender was 24.6 weeks. I won't bother you with some of these figures, they're really quite disgusting for instance. In New Brunswick, there was a wait time of 58.7 weeks between diagnosis of a urological problem and treatment. Despite these data, a number of commentators who favor the introduction of a Canada-like system have argued that wait times in Canada are really not out of line with those in the United States. And indeed, in a lot of cases are less burdensome. There is an organization called Physicians for a National Healthcare Programme and another called the Californian Nurses Association. Both organizations actively lobby for the introduction of a single payer Canadian-type system in the United States. And both have repeated the claim that the on average, the wait time to see a physician in the United States is 70 days. I don't know where they came up with that. Wait times of course are in fact substantially longer in Canada than they are in the United States. And even the Supreme Court of Canada has claimed that 95% of patients wait well over a year and many two years for knee replacements. Let me read you from a case that came before the Federal Supreme Court in 2009. There is no dispute that there is a waiting list for cardiovascular surgery for life-threatening problems. Dr. Daniel Doyle, a cardiovascular surgeon who teaches and practices in Quebec City, testified that a person with coronary disease is quote sitting on a bomb and can die at any moment. He confirmed without challenge that patients die while on waiting lists. Invariably where patients have life-threatening conditions, some will die because of undue delay in waiting surgery. So these wait times must be added. The waiting time spent in medical offices waiting to see a physician, one of my particular paves. It is an invariable practice in Canada to double or triple book when you make an appointment with a physician. So even though the appointment might be three weeks out, you will have the same appointment time as one or two other people, which means invariably you will have to wait in the doctor's waiting room for some time. Two hour waits are not uncommon. And physicians seem oblivious to the fact that time has some value to those other than themselves. Under the Canada Health Care Act, there is no incentive for a physician to be prompt. And in fact, the more patients he can squeeze into his schedule, the higher his income. Nor need he be concerned that he will lose patients since the demand for physician services at zero cost is close to infinite. Not only must Canadians wait to see a specialist or to undergo treatment, but the wait to employ advanced technology for certain diagnostic tests is equally long. It is worth pointing out the PET scans, positron emission tomography scans, are totally unavailable in Canada on the Republic Health Care System. The medium wait time in Canada to access an ultrasound is 31 days. To access a CT scan, 30 days. To access an MRI, 69 days. And there is a range that can go much higher depending on what the tentative diagnosis is and what province you live in. Wait times for MRI are 16 weeks in Ontario and 112 days in the Vancouver area. 112 days. Contrast this with the wait time in Canada at veterinary hospitals. You can get your dog a CT scan or an MRI within a few hours. Canada's record of investment in these technologies is the worst among industrialized nations. The number of MRI units per million is 6.7, which is half the rate of the OECD and about one quarter the rate of the US. It has half as many units, MRI units as does Greece and Korea. One third the number of units as does Italy. Now, I tried to check the particular datum and I wasn't able to find where I had originally read it. So I repeated the number of units so I repeated to you with the caveat that I'm not sure where it comes from or whether it's completely reliable. But I did read somewhere that the number of MRIs in the Arabian desert during Desert Storm was greater than all of the MRIs in Canada. In 2008 Forbes magazine noted that there were more MRIs in Pittsburgh than all of Canada. Even in less developed equipment, Canadian healthcare system is often reluctant to make these available to patients because of cost. I won't go into that, that's unnecessary. In the face of these horrendous weights, which occasionally result in the death of patients, there was substantial opposition to the introduction of privately run MRI clinics. A group of doctors in the province of Alberta and also in British Columbia decided to get together and set up a private clinic where they would not provide hospital or physician service but simply these diagnostic tests. However, there was a huge you and cry tremendous opposition to this on the part of large number of Canadians because it was felt some Canadians would be able to, quote, jump the queue. And that would in turn allow for a two-tier system of healthcare. The first private MRI clinic was opened in Calgary in 1993, but at the time of the 2000 federal election, the Prime Minister Jean Chrétien vowed to withhold funding if any province allowed such clinics to continue existing. So mean-spirited were a large number of Canadian voters that they were outraged that anyone could buy quicker service. This despite the fact that one result of these private clinics was to reduce the waiting time on public facilities. The group in the lead in opposition to these private clinics was, of course, Tommy Douglas and CCF and also the Canadian Union of Public Employees that argued that the National Canada Health Act, to which all the provinces had subscribed, implicitly disallows payment for any medically necessary hospital and medical services. That's diagnostic tests, physicians, now hospitals. The number of acute care hospital beds in Canada has been steadily dropping for 25 years. In 2007, it was 2.7 per 1,000 population down from 3.9 in 1995. Now although the number of hospital beds available in Canada and the United States currently is about the same, there is a quirk in the Canadian system. Much of the difference is because hospitals are financed in Canada by block grants that are given at the beginning of the year. You get X number of dollars to operate until the end of the year when we reassess and give you another grant for the succeeding year. Now that being the case, patients who are more seriously ill are less likely to find a bed in a Canadian hospital than someone who is less seriously ill because it's cheaper to deal with a less seriously ill patient. So the result is that hospital stays tend to be longer in Canada. In the US, they get you out right away and somebody as critically ill as you were when you entered can take up the hospital bed. That is less true in Canada. The average length of stay in Canadian acute care hospitals was 7.6 days in 2009 compared with 4.8 days in the United States and this is true over a whole range of illnesses and the shortage of available beds in hospital ward and intensive care units necessarily leads to much longer wait for admission and too long waits in emergency rooms where patients are often warehoused while awaiting admission. In April 2011, I discovered this the other day, the health minister of the province of Alberta boasted that the province's attempts to reduce emergency room wait times was meeting with success and that medium wait times for patients in hospitals in Edmonton had been reduced from 16 hours to 11.6 hours. Finally, physicians. There is a serious shortage of physicians in Canada for obvious reasons. One way you can reduce the expenditure on healthcare is simply by reducing the number of physicians that are available to patients who stand in line to see them and this has been done. So the shortages of deliberate consequence of policies pursued by the Canadian federal government to reduce admissions to medical schools and the number of training positions available and contributing to this shortage are restrictions on licensing of immigrants who are physicians to Canada. Now, despite the evidence deficiencies of the Canadian medical system in almost every particular, it remains enormously popular among Canadians who are regularly bombarded by propaganda, much of the generated by the government and by those organizations with a vested interest in perpetuating the nation's current arrangements. In a joint Canadian U.S. survey of health conducted in 2003, no less than 87% of Canadians indicated that they were very satisfied or somewhat satisfied with the healthcare services available to them. The number of those satisfied almost exactly equals the number satisfied in the U.S. The average Canadian has led to believe that in the United States, someone seeking healthcare, sorry, someone seeking healthcare either finds himself uninsured and health and hence without access to medical care or else faced with bankruptcy because of the prohibitively high costs for medical services. Most Canadians appear to believe that before a critically ill patient will be picked up by an ambulance or admitted to a hospital in the United States, they must either first present proof of medical insurance or at least a credit card with huge limits. In fact, the overwhelming proportion of Americans, of course, are in fact covered by some form of health insurance. In a study undertaken in 2009, the Census Bureau estimated that approximately 51 million people or 16.7% of the population had no medical insurance. However, in reality, the number of people who are effectively uninsured that is those who seek medical insurance but do not have access to it is almost certainly considerable and small for a variety of reasons. First of all, the larger figure is in part the fault of the Census Bureau's survey, which consistently underestimates the number of Americans who are entitled to Medicaid. Where these differences taken into account, it would reduce the involuntarily uninsured by about 20%. Second, if we analyze the incomes of those who are uninsured, at least 25% of them could, without great difficulty, afford medical insurance if they chose to purchase it. The U.S. Census Bureau reports that almost 20% of uninsured Americans live in households with an income of at least $75,000. Even if this half, even if only half of this number are uninsured because they themselves are unable to afford it and they live with other richer people, the remainder, about 25%, are uninsured by choice. Third, the fact that medical insurance in the United States is regarded by the IRS as a non-taxable benefit is almost certainly associated, which requires that it be associated with one's employment. This could be reduced substantially if either medical insurance provided by one's employer were taxed, as it would be if you were to buy it being self-employed, or if it were exempted from tax if you were self-employed. Given these facts, there are also problems with illegal immigrants and so on, but I won't go into that. Given these facts, it has been estimated that the actual number of people lacking insurance for non-emergency services is actually about 5%, or about one-third of the official figure of 15%. Of this, 27% are illegal immigrants who come from nations where private health insurance is unnecessary. Additionally, only legal immigrants who have been residents in this country for at least five years qualify for public insurance. Finally, more than half of those uninsured are fairly young and of these a substantial number are likely to regard medical insurance as unnecessary. It's worth emphasizing that American hospitals are required by law to provide treatment to stabilize the sick or injured, regardless of the patient's ability to pay. This requirement does not absolve those who receive treatment for paying for their hospitalization if they can afford to. It is only in instances where they cannot meet the costs that patientism is absolved from paying. It is not the indigent, however, that concerns the average Canadian who so staunchly opposes the healthcare system as it operates in the United States. His concern centers on the middle class who would be faced, almost certainly faced, with a staggering debt without insurance and consequently has compelled to spend tens of thousands of dollars a year to avoid this contingency. In the minds of most Canadians, the alternative to the burden of private insurance is a government-run system which they regard as free. Since their healthcare is financed through taxes, there's no real sense that they're actually paying for medical and hospital services and they certainly don't count their waiting time at some cost on them. This seems to be the only reason why Canadians are so wedded to their system and so opposed to the American alternatives. Yet in almost every particular, the Canadian healthcare system falls short when contrasted with that in the United States. Given its limitations, shortages, long queues for diagnosis and treatment, widespread inefficiencies, it's hard to believe that Americans would tolerate a Canadian-style healthcare system. Those who support its introduction are either unfamiliar with its characteristics or are motivated by private interests that lead them to distort the truth. There are serious problems inherent in the current American system but the Canadian example hardly offers a solution to this. Thank you.