gonna be talking about DevOps practices and how it applies to the database team. And what I believe, right, so generally just humble kind of made this statement sometime back and basically rapidly changing, automated and all that stuff, that's what DevOps is. So fine, like what does it mean? Developers basically create stuff and do the stuff and ops people in which some part of the DBA sits on the ops side. So they kind of assume that it's not my machine, it's your code and the developers say it's my code, it's your machine that's wrong and all kinds of stuff happens here. So let's see how we can break, like break this thing. Like one is incentivize, I think Katie talked about incentives here. One is incentivize to deliver faster and the other is incentivize to keep things stable. And that's where the crux happens. So how do you improve this, right? Like how does this make it sense? In reality, I think all of our jobs is to basically help business deliver so that they can respond to changing market needs, right? That's all of our job. Doesn't matter which side of the shop we sit. And that's how I see DevOps too, right? It's our job to keep the business nimble enough so that they can deliver whatever changes are happening in the market. They can react and respond to those changes. So what does it mean to be DevOps enabled on the database side, right? Like what does it mean for developers? What does it mean for DBAs? What does it mean for everyone else? So let's say some of these, like I call these practices, you can call this like stuff I have learned over a period of years, things like that, right? Basically you need to pair your DBAs and developers. Like in whatever they are doing, like let's say they're creating a schema, creating this, creating that, they need to pair, right? To pair on whatever solution they're gonna come up with. Instead of like the developers coming up with their own solution and throwing over the wall to the DBAs, like now make this run in production, it's not good, right? Like you said, why don't you bring the DBAs earlier in the life cycle so that they have an input on the solution that's being developed, what kind of design you're coming up with and things like that. This also allows continuous learning on both sides, right? Lot of times DBAs are used to seeing lots of volume, lots of things that happen in production. The developers are happy with their like 10 customers and 20 orders in their like test data and like this thing runs awesome with 10 customers. But you go in production and there's like five million customers, stuff breaks, right? The DBAs know about that and you can use that input while developing. So the other big thing is like put all of your database artifacts along with the other artifacts of your application. If your database is supporting more than one application, make sure all of your database artifacts are in some kind of version control that everybody has access to. They can see and stuff like that. There's nothing magic about what goes on in a database like schemas or if you're stored products, triggers, whatever you have, maybe on backup scripts. If you have like ER diagrams, if you have data flow diagrams, put all of that in version control. So if someone has a question about something, you can point them exactly where it is at and they can take a look at it on their own time. Like it's not version control on a DBAs desktop or it's not version control on a DBAs laptop, right? Put everything in version control, doesn't matter what kind of artifact it is. And like here's an example of this stuff, right? Like we did some time back like everything about the database is in a DB folder inside the same applications folder and we got script for performance data, we got scripts for like maintenance, database admin, whatever you have, all of it is in one place. If there's some special data for quality testing, fine, that's also in there. So people can look at it and look at a history of this stuff. This also enables auditing, right? Someone sees what happened here, everything's there, you can look at version control and that kind of stuff, figure out all the auditing. Another part of this is generate as much as database boilerplate code. Like there are lots of triggers people put for auditing purposes, there are lots of like simple views people write, synonyms you can call about like grants, all kinds of stuff that people do in the back that are handwritten. You don't need to handwrite that. If there is a pattern to that code, just generate the heck out of it in a pipeline and you don't have to think about it again. Like someone changes a table definition, someone reunions a table, someone does this, all of that can be generated and applied in a pipeline so you don't have to hand code this stuff. And you can, here's an example of like one of our clients that I was working with, they wanted to have a database like within a schema and that schema cannot have like direct access, like applications cannot access it directly and it has to be accessed via like some other schema that had read access, write access and that kind of stuff. So I could have sat there and written all of these grants myself by hand and as the tables and schemas changed, I had to modify that script. I just wrote a small Ruby script that basically generated all the grants and created all the synonyms, put it in a pipeline. So whenever a developer changed a table, renamed the table, added a new table, we had a new script that got applied automatically and I didn't have to look at this part of the job at all again ever, right? Because I have automated myself out of that job. And by the way, automating yourself out of a job is a good thing. That's how I believe. Like if you have automated something, then you can focus on something that is more higher value, more important to the company than keeping on doing it manually, right? So here's an example of automating some stuff. Like you could use Docker images to basically get like standard set of a database for someone, like for some kind of development. There are like usually think of like a complex set of test data so that developers can work with. Think of like a standard set of customers, especially in a PII or HIPAA compliance or PCI compliance, those kinds of environments. If your setup data is complex, you can create a Docker image that has like a set of 10 customers, a set of 10 addresses, interlinked and all kinds of complex setup done. And you can publish that out so that the developers can just pull the Docker image and start working against it, right? Instead of having to like manually set up that stuff or use some kind of code to set it up and some requirements change. Now the code needs to be changed and all that kind of stuff. So in many places I have used this kind of setup where there is some test data, it works against a schema. You basically put it in a database, create an image out of it and then then you can publish that image out via a pipeline and then you could use it for whatever kinds of testing. Like sometimes like think of functional testing, unit testing, integration testing, even sometimes like complex performance testing if you have some kind of stuff going on. So that kind of pipeline is super important to abstract you away from the complexity of setting up test data, right? So it really helps you and the DBAs and the developers can focus on how I can get my test data into that original schema and then the rest of this stuff works through a pipeline and I don't have to worry about how I get my schema setup, how I get my data setup and all kinds of other questions just go away, right? So here's an example of one other thing where I let developers provision their own database, like not worry about like let me create a database for you, let me create a schema for you, let me put some reference data for you, all of that I'll just abstract out, put it in a build script so that when they basically check out from the code base they can literally like create their own schema, create their own tables, create their own data within that stuff. So here's an example of how this flows. I just, hopefully people in the back can see code here. So I just did a git clone of a GitHub repo. I'll basically point it to a database that I'm using. So that it works against a schema and it creates a schema for me. It's logging in as a system user. I'm showing Oracle example here, but it logs in as a system user and creates a schema for me and the moment I clone my repo I can get a schema for myself without having to worry about or getting into this mess about sending an email to a DBA and that kind of stuff. It also frees up the DBA from doing these kinds of mundane tasks, right? So again I can concentrate on more higher value things I want to do. Simple stuff that can be done. So the ant creates schema here. I know ant is like out of fashion right now, but I'm just showing so that it creates schema. You could do the same stuff with like Maven or Gradle or Rake or whatever it is, doesn't really matter, but you can automate that step so that you get your own schema without having to worry about how do I do this for others. The other important thing is when you are doing or when you're working on application development your database schema is gonna change all the time. I mean that's what entails when you are responding to market changes, right? Like when your business is responding to market changes it forces some changes on your application which forces changes on your database, right? So your database is constantly gonna change. So instead of waiting for the time of deployment to figure out what changed, it's better to basically do it in the early phases, right? So and one of a good example of doing this or how to do this is basically using database migration frameworks. And here's a list of some of those.   Like if you use Java, you can use one of some of this for Ruby. There's the Rails framework, Rails migrations. If you're using .NET, roundhouse, I guess. There's also some commercial software like DB maestro, Redgate, Datical. So if you are into the business of deploying changes to your database, please use a migration framework. Don't try to do this manually using your own scheme or something like that. So here's an example of how this migration framework works. Again, like you're basically saying I want to like make this stuff work. It's working with my schema here. Malmo in this example, right? And then it's taking a bunch of changes that I coded and it's also doing like some test data. It's also doing some stored procedure code, trigger code or whatever it is. Like all of this is built inside the build script. So it runs the same exact way for every person who is using this. Like doesn't matter developers, doesn't matter QA, doesn't matter DBAs. All of this stuff is running as is or similar to a set pattern like repeatable, right? That's one of the things that is very important is does it run in the same fashion for everyone? And this is a repeatable script that you can set up that works for everyone. Of course, who has not been in this situation where your database is used by your application and a bunch of other side projects that tend to use your database. So this is like the standard database level integration that's happening and every enterprise kind of goes through this, right? So if you are in this kind of situation, then you are wondering if I'm pushing changes to the database constantly, will it not break others? Like what if a report is running that is using the customer table and I rename the customer table to client or I split the table to use something else or a bunch of these kinds of changes, right? Like breaking changes. Because in a lot of ways, your database is an interface to the data. The database schema is an interface to the data and if you break that interface or you change that interface, your application is gonna break, right? So imagine someone changes the customer table to be called client and suddenly a bunch of stuff doesn't work anymore, right? So to tackle with this, there is this concept of database refactoring that me and Scott Ambler wrote about long time back and the crux of that concept is there is a timeline for a change, right? When you start making a change, there is a transition phase when you wanna keep the old and the new, like client and customer table names both work at the same time and at the end you say, okay, I'm done with this customer table, I wanna call it client from now on. So think of like whatever four or five slides I'm gonna talk from now on. Think about this pattern of you're starting a refactoring, there's a transition period and there's the end period for that. Like just like how you would do with any APIs, right? Like you start with the API and then come up with a new API, you are gonna put this old API in like deprecated mode and like maybe a year later you take out that old API. Same concept applied at the database level, right? So let's look at this concept and there is this thing known as expand and contract. So I'm gonna talk a bunch of examples here. If you are not used to seeing SQL code or SQL scripts, I apologize right now.  There's also a link to that at the end of this. So no need to take notes right now, right? So database refactoring just like code refactoring is you need to preserve behavioral as well as structural semantics, right? Like informational semantic. If it was a customer before that stored customer data, you call it something else, it still needs to store or basically have customer data. If you lose that customer data, a lot of people will not be happy with you, right? So keeping the old and the new working, that's the crux of refactoring, right? So let's look at an example, like an expand example here. I have a customer table in which I have a customer ID and a name to begin with. I'm like, oh, this is not good. I need to split it up with like first name and last name here. So I put on like customer ID and first name and last name as two new columns. And the name is still there. That's my expand phase. And at the end, I will end up with just like customer ID, first name, last name. That's my thing. So let's look at some data examples here. Like I start with name as promote, and then I'm gonna split with promote, and promote, and promote, so that is still in the table, right? And when I'm done with this, I'll have like first name and last name split up. Now at this point, there are multiple choices you can take.  No need for that middle stage at all, right? I don't have any customers, so I don't care about this middle stage. But like most companies that have existing data, you are gonna be in a situation where you want to preserve that data. So that's your start. So I can do this without migration, right? Like for example, I'm not doing any data migration. Here I'm actually splitting the strings up, like using a space as a delimiter and stuff like that, and I'm gonna split that up, right? So two options that I have, but I ultimately end up with, and we end up with the option where first name and last name is what ends up in that database. So here's a very simple scenario. Like I'm adding two columns, and I'm done, right? Because let the application take care of reading the old column, and when it persists, it'll persist as a new, like two different columns. So this I call as lazy migration, right? So the application is dealing with it. The database has nothing to do with this, right? So one other option is with synchronized data. Like when I add those two columns, I basically put in a trigger that says when someone writes to the name column, split the column up and write to those two columns. When someone writes to those two columns, combine them and put it to the new column. So whenever someone comes to the table looking for the name column, it has data that they're looking for, and someone coming to the customer table looking for those two columns, it also has data. So now you're keeping old and new, active at the same time, and data is being synchronized constantly, right? Now you can make one more variation on this, is you're synchronizing and you're migrating at the same time. So first time I add these two columns, I'm gonna migrate the data up so that all the existing data is taken care of. And in the future, when people use both those columns, I'm gonna also take care of moving the data around. So again, I'm keeping old and new happy. So think of all the reports or all the other feeds that you're sending, everything, they're all happy. So I can also, in the contract side, I can just drop this. You imagine you have 100 million customers or 100 million rows in this, this table's gonna get locked for like 15, 20 minutes. And if you care about uptime, then you don't wanna do that. Find some time when I can take that lock so that I can then drop it. So when drop takes forever, like you have database features that basically say set unused, the column just goes away from the metadata, but it's still there, right? That happens very fast, gives you higher uptime, but at the same time doesn't take away the data or the column, and you can take it away later at a Sunday night or some kind of weird time like that. Again, it can be scheduled out, but again gives you more options to deal with, like uptime and that kind of strategies, right? Even then there will be some apps, like I think Katie talked about like 400 or 1,000 apps in her enterprise. There will be some apps that nobody's working on that still want the name column there because nobody's putting any effort to migrate it to the new structure. So how do you take care of that? Like you can again add a virtual column called name, and if someone accesses that, I can run time, generate the name column and show it back to the user. So again, their interface to the database doesn't break. Of course there's a cost to this, like how long do I keep this interface alive? But again, if you're willing to take that cost, then you can always add this up and give it back to the users, right? So again, this is a way to keep the old and the new happy because we are again constantly deploying and when you're constantly deploying, you cannot guarantee that all the apps that are using your database can be deployed at the same rate that which you are modifying the database. So this is a good way to give them an interface to your database that doesn't break, right? So the next thing is to put your database under continuous integration. So if you are in this kind of shop where the DBA team basically is applying changes to your Dev database, to your prod, UAT, QA, please, please, please get away from this, right? So if you are gonna be doing this, the DBAs need to start pairing with the developers at the very early phase of writing the migrations itself. Like you are pairing there doing schema design, you are pairing there doing index design, all kinds of stuff. And you are writing the migrations there when the stuff is actually being designed, right? Then you are gonna put them in whatever version control system. I'm showing git here, but whatever version control you use, which is other than a database DBAs laptop, that's good, right? So you want to use it here. The continuous integration engine, again, whatever you use Jenkins or Go CD or whatever that you are using doesn't matter as long as it has its own copy of the database. Remember how this is DevDB here, this is integration database here, different databases. Again, we want to run this on a whole different stack and make sure it works instead of running it on the same thing again, right? So you can, again, you can use like Docker images here, like I can spawn up a new database, run this whole thing again, verify it works, and then go forward so that you are not in a situation where this thing works on my database or works on this. You are applying the same migration scripts, no changes, like whatever you checked in got applied again. You can take that further and package your database scripts, database migration scripts, just like how you package your applications. It could be you are generating a zip file for the database and a jar or a ur or a var for your application stuff. It could even be like a tar if it's Ruby land or whatever that is. Whatever package you generate out of this, you generate the same package for the database side and then you apply the same package to whatever environment. So no custom coding when deployment time comes, right? So that gives you a lot of traceability for auditing purposes, a lot of traceability going back like what mess my environment out, right? So you can use that for that purposes also. So here's an example of how I would put this, like there's application jar and there's a database upgrade zip and they go both hand in hand. Like how many of you have ran into a situation where you deploy the app and it comes up, it says column not found, table not found, view not found, all kinds of stuff happens. If you are into that situation, this will totally avoid that because the app ran against the database that you packaged and deployed together, right? So you are basically giving up the notion of DBA controlling the database to like it gets verified at the CI engine level and then gets packaged so that it can be deployed lockstop barrel along with the same versions of the application, right? So of course this comes like the next step is like physically the database in production is so much different than a developer's database. Like how do you abstract that out, right? So here's an example, like generally on the developer side I have like very simple stuff, one or two table spaces, everything is crammed into that, but in the production side I am split out, like maybe some highly used tables are put on a SSD versus some low usage tables are put on spindles and all kinds of stuff happens on the production side. So how do I make sure this abstraction doesn't bite my developers because they are designing tables that get put on the same table space and stuff like that. So we came up with a very simple map. So in developer docker images or whatever you wanna call them all the tables go into basically one table space, I don't really care, right? But as they move up the environment I can create a map like this table needs to be in this table space, this table needs to be in this table space and the pipeline I basically run a script that basically moves those table around in the right table space. So the developers don't have to worry about and the DB had made this mapping once and then he doesn't have to worry about it again either. So any new table gets added, I just need to update the map and the pipeline takes care of pushing it in the right table space automatically, right? So in this scenario I'm saying like basically take a table and move it to whatever table space that it's supposed to be based on this table space map that I've created, right? So it's a very easy way for DBS to determine what goes where. During development time and not have to like force developers to have that complex setup on their developer workstations or in their developer images and things like that. So it gives you a very easy way to move stuff around. You can also automate the database change deployment, right? Like deployment should be as easy like I can say deploy DB, upgrade QA and QA gets upgraded to the latest version. If I say deploy DB, upgrade production, production gets upgraded to this. And when it's this easy I call this the boat metaphor, right? Like deploy frequently is a boat metaphor like imagine you are on a shore like maybe Michigan lake. There's a boat that goes from like the Wisconsin side to the Michigan side like once in six months, right? And there's no other way to go from Wisconsin to Michigan just imagine that for a second, right? And if there's only one boat that goes once in six months everybody's gonna be like I want to get on that boat like I don't matter what happens, right? Same thing happens with your applications too. If you're releasing once in six months everybody wants their feature in there, right? And for that they're gonna do whatever it takes and for that we are gonna cut quality corners, we are gonna cut like all take on all kinds of risks. We heard about like three day deployment windows and that kind of stuff, right? If you deploy frequently it relaxes people. Like I can go to Michigan from Wisconsin in this boat like every Tuesday. That suddenly like reduces your stress level and makes you happy that oh if I miss this boat I can chill out a little bit maybe drink some Wisconsin beer and then get on the next boat here, right? So if that is the way you put this up to people then it relaxes and it reduces stress on your teams also. And if something's risky doing it more often reduces the risk. It's kind of weird way to think about it that way but if something's risky do it more often it will suddenly reduce the risk of doing that thing. So I say deploy more frequently and once you start deploying more frequently using this automated techniques using these refactoring techniques of where you keep old and new alive using like automated way of like managing using CI and CD pipelines for this kind of stuff it will reduce your risk and you can literally like deploy every Tuesday. I have done this many times where you deploy on a Tuesday like at 5 p.m. you start deployment, 5, 10 you're done and then you're free back to like doing your normal stuff. Right? So this kind of deployment pipeline helps you reduce risk and at the same time freeze up the DBAs to do valuable things and the valuable things are during application design like how do I partition this thing? How do I do the index design? How do I structure tables? How do I do all kinds of stuff? That's where the value is. And I have talked a lot about relational databases and I know nowadays like no SQL databases are in OOG same kind of stuff applies to no SQL databases too. Right? Doesn't matter if it's released on like non relational databases, same kind of techniques apply on both sides maybe with a little bit of difference because there is no schema on no SQL and there is schema in the relational databases. Right? That's all I had to speak. I have like I said, some books about techniques I have written a book about no SQL and something about databases and CI stuff. So I'm open to questions. Sure. So where I am now we have a using liquid base for everything, which is nice, but we don't really have developers spending any thought on rolling back changes. Do you have any advice on how to work together with developers to encourage them to consider rollbacks and maybe convenient tricks or simplifications? Because a lot of the things like, well, you know, if I just added a column that's easy to roll back. Yeah, rollback was in like high demand back in like maybe 2006, 2009. And since then people have shifted to like not rolling back but rolling forward always because rollback is a complicated thing to accomplish. Like let's say I renamed the customer table to client. Like rename that is fine. Like it's very easy, space management wise, but what if I split the table, right? Like now when rollback means I need to join the table back or let's say I drop a column and the rollback basically means bring the column back. So bring the column back. Like I can just put the column there because I need to put the data also there. That means I have to keep a copy of that data as of that instance around. It gets really complicated. So nowadays people are like, I always keep rolling forward. And if there are any errors, I will like roll forward further to fix that bug, right? So nowadays the technique has been like keep rolling forward. And one of the coolest techniques I have done like maybe a year back was the database is always rolling forward like iteration or maybe two weeks ahead of the application, right? So if I need a column in this table like two weeks from now, the database has it now. Like that kind of technique. It helps us to like roll it forward and take care of all the performance implications of adding columns or splitting tables, stuff like that in production when volumes are really high. So I can take care of that and the application catches up like two weeks behind or one week behind based on your tolerance for that kind of stuff. I will, if I remember, and I'll try to really remember. So Mark Burgess has a really good, an article he wrote a few years ago about the myth of rollback that I really love. So I'll try to remember to drop that in the Slack channel or I'll just ask Paul to go find it and drop it in Slack for me. So that'll be rad. Hi, so my organization has adopted most of the patterns you've suggested against. And I guess my question is where do we start? Right, so the first thing I would say is back in, maybe I'm showing my age here, back in 2002, we were running the same situation with the client. And the first thing I would say is you need to bring people together. I think in the big morning we saw this is a people problem. This is not necessarily a technology problem or like technique problem, it's more of a people problem. Like DBAs who are used to doing certain things, they'll say I'll probably lose my job when you automate all of this. That's not the case. We are saying just come up the value chain and help collaborate there, right? So that kind of stuff is very important. And the way I saw that problem was, literally I told to the DBA team on the client side, like let's have lunch one day a week and we go sit together and just talk. Nothing about implementing this, nothing about anything like that, but let's just talk. You need to gain trust to implement this kind of stuff. You need to show them that we are not talking about automating someone out of a job, but it's more about reducing risk. It's more about getting good sleep at night every day instead of like three days a night or something like that. So it's more about that. So I would focus more on how do I gain trust and how do I take them to the next level of understanding of what I'm trying to propose. Generally people walk into this kind of conversation with fear and then from there it just a closed door conversation doesn't go in. Hi there. There was interesting this stuff you showed about when you're upgrading the schema and you have the backwards compatibility for old clients. I was wondering if you had any suggestions for visibility of which old clients are using these deprecated columns and things other than DBA looking in the logs. Yeah, so again, some kind of that kind of stuff. Tooling-wise databases don't generally provide you tooling and say this table is being used in this particular application because as you see those are API level abstractions. Imagine you publish an API to the public. How can you tell which person is using which unless they actually call the API, right? So you can put some kind of abstraction on top like a schema on top that has like read-only access and then make apps run through that and see who logs in and you can figure out what kind of people are coming in, what kind of apps are coming in. You can also put some kind of triggers to see what kind of access is happening at the table level. Again, triggers help you with like update insert and delete not trusted with selects, right? So that kind of login level triggers can help you seeing who is accessing this stuff and then the best method, like I say, compile is a unit test, right? Like who have heard compile is a unit test, right? Similarly, you just drop the column and see who complains and then you know who is using it, right? That's the last resort by the way. Excellent. Thank you so very much. Let's get another round of applause for Rod. Thank you.


Okay, so throughout the years, one of my main efforts has been making sure that catapult plasma panels are as powerful as can reasonably be. I've implemented floating panels, but also adaptive transparency, margin areas and lots of other features. However, it's not surprising that other desktops have taken different approaches and it's really useful to give a look at what they are doing and sometimes say, hey, they beat us. What happens? Spoiler alert, plasma panels in this video will be completely destroyed by Cosmic and XFC. I really want to make this comparison firstly with Cosmic panels, even though currently Cosmic hasn't been released yet. However, there's a blog post by System76 that explains how they're going to work in super details and some things are genuinely better than what we currently have in Plasma hands down. You want an example? You can stack multiple panels on top of each other. Plasma can't do that. If you're out of the loop on Cosmic, by the way, it means that you don't know about the newsletter. In fact, this video is sponsored by the TechEd newsletter. I'm actually the primary writer for this newsletter, so if you like my content, you're going to like it. We come out with one weekly covering the latest in Linux open source and tech news. First in our last publication, we covered all about these new Cosmic panels, but also Thunderbird goodness and more. You can subscribe with your email for free or if you're not into that, you can also use the RSS feed or just bookmarktechEd.tv and see all the latest news, but also guides and articles. Make sure that you check out the first link down below in the video description and subscribe. It is worth it and there is absolutely no conflict of interest in me saying that. Anyway, the other system I want to compare is XFC, mostly because I've tried their panels recently and I've realized that they actually beat plasma panels in many areas. As an example, as we'll see, they're able to freely float on your screen something that plasma panels can't quite do. Can they? Well, we'll get to it. Position Let's start off by talking about positioning of the panels. PD Plasma panels can simply be drag and dropped on any side of the screen and just like that, they are already more powerful than Windows 11 panels. And you can also drag and drop them between screens. If the panel does not feel the full width or height of the screen, you can also move them around whilst keeping them attached to the screen border. On Cosmic, on the other hand, you don't drag and drop things around. You can however open up the panel settings, which live inside system settings, and you can change the screen side in just a combo box. Just underneath that, you can also have the option to choose which display to show the panel in. And this is the important part. You can choose to display the panel on all displays, meaning that the panel will be in multiple places at the same time. This is not something that's offered by Plasma panels, and it's actually a quite requested feature. Most importantly, when you set multiple panels to have the same screen side of the same monitor, you will end up having them stacked one on top of each other, which looks really great and is probably what the user would like to see. Instead, in the Plasma world, having panels on the same screen side will simply draw them one on top of the other, which is just going to look like a glitch. Let's make wins this one like hands down. So let's switch to XFCE. Ok, they have this dialogue to quickly customize the panel without having to open up settings. However, as I mentioned in my other XFCE video, I found the dialogue to be really messy and hard to understand. You can switch the panel between horizontal and vertical, kind of, there are two different kinds of vertical, to make it switch between screen sides. But the cool stuff begins when you untick the tick by default lock panel option. This allows you to drag and drop the panel anywhere on the screen, even if it's not at the screen sides. You can position it anywhere in any orientation and move it around as a normal window instead of having it always fixed in the same place. Most importantly, you can create multiple panels and place them one on top of each other to replicate the cosmic setup. Multiple panels cannot do that. Kind of. So this is actually pretty funny. All the necessary code to make panels float around is there already and we do use it for when you drag and drop a panel. However, we don't really allow any customization where the panel isn't attached to the screen side. So yeah, we do not offer that. And yet again, I feel like XFCE easily wins this one. So let's switch to size. So the thickness of the panels can be customized in all of the systems. And it's kind of the same. But what we are really interested in is the width or height of the panel and how it change. In fact, when it comes down to size, Kali Plasma has it big. Kali Plasma allows you to customize not only the size of the panel, but you can also set the minimum and maximum panel sizes. The panel will then resize to be within those values. Depending on the size of the widgets within it, which I think is pretty cool. However, there's a pretty big issue with this approach. I see so many people not understanding how this is done at all. And to be completely honest, every time I have to drag and drop the panel size handles, I always pick the wrong ones. Always. So let's look at Cosmic. You cannot set a custom size for the panel. You can just set the thickness. However, what you can do is tackle the option called expand panels to the screen edges. If it's on, the panel will always fill the available width or height. If it's off, it will just have the same size as the applets within it. This is something you can do in Plasma. You just have to change the alignment to center and then drag and drop the correct size handles to be as small as possible, whilst keeping the other ones still. However, Cosmic option covers the use cases of the vast majority of people and it's so much easier. I've seen Plasma people without a clue that this way of doing things was even possible. Again, I think Cosmic approach is straight up better compared to ours. So hear me out. I've decided to change our approach. I will hide the weird ruler by default and simply have an option called like panel type with three options, full width, which is going to maximize the panel, dock, which is going to fit the size of the applets inside of it and custom, which will make the rulers appear. This way, it's still super powerful for everyone, but it's much simpler to handle by default. By the way, all of my development work is not paid by KDE, but it's actually only thanks to all of these amazing people around me that sponsor my work. So if you really want to see Plasma panels improve and you haven't yet, feel free to throw some spur change at my people, Patreon or LibraPay or Kofi. Do you want to hear another sizing issue where Cosmic straight up beats Plasma? Okay, so let's say that you have a vertically maximized panel on the left screen side and a horizontally maximized one on the top of the screen. So question, what's going to happen in the top left part of the screen? In KDE Plasma, the panels simply overlap and you will see only the last one that you clicked, which feels like a glitch and it is really on the other hand, a lot of thoughts was put into this during the design stage at Cosmic and there's actually two rules for corner priority. The panel will always take priority on the dock unless it's floating, as the non-floating panel always has priority on the floating one. But at least they won't overlap. Another point for Cosmic. So let's switch to XFC sizes. So finally Plasma holds up here, since you simply have a slider that customizes the width or height of the panel. They however do have a setting called automatically increase the length, which addresses the issue of fitting to the size of the outlets. But if you really want to go with this approach, I'd actually prefer the idea of having a minimum and a maximum size and not so clear to understand the checkbox. Note, however, that you do have rows in XFC panels, which is something that initially I wanted to implement in Plasma panels too, but then we decided not to. It's an interesting feature that basically allows to do what Cosmic is doing with double panels but just using one. For this reason, I'm still going to give XFC a full point here. Eye candy. So let's talk eye candy and let's immediately start off with opacity. One loves a good transparent panel, right? Well, not quite, but in KT Plasma the user can change the opacity of the panel, either by changing the Plasma theme or by switching between the opaque and transparent options. However, that's kind of it. If you're using as an example a third-party theme that does not support adaptive transparency and you do not want to edit theme files, you just cannot change the opacity. This is actually for technical reasons, by the way. On the other hand, Cosmic gives you a full slider that goes from completely opaque to transparent and you can fine-tune it to be your liking. And this would be another easy win for the desktop, but thankfully Plasma has a very neat feature that Cosmic hasn't, adaptive opacity. KT Plasma panels can change their transparency depending on whether a window is touching them or not. Personally, I believe this setting is actually extremely important, as I do want my panel to be transparent if I have some floating window, since the panel will blend in with a background nicely. But if I have a maximized window instead, there is no background to blend with, so it doesn't really make sense for them to be floating in the first place, in my opinion. The same exact thing applies to floatingness. Both KT Plasma panels and Cosmic panels support floating panels, and they call them having gaps between panels and a screen border, fair enough. However, Plasma panels are adaptively floating, meaning that, again, they will defloat whenever a window touches them. So I think that in terms of ICANN, the Plasma is actually at least competitive, especially if you consider that you can completely customize the colors and look of the panels too. It's a very similar story with XFC, so let's start with opacity. Yet again, they have a very nice feature that's simply impossible to understand without reading the documentation. Basically, you can set different opacities for live and for enter. Now I will give you 5 whole seconds to think and try to guess what these two different values do. Go on, editor, insert 5 seconds of silence here. Okay, here's the solution. Hover is the panel opacity when you're hovering the panel with a mouse, whereas live is the opacity when you're not hovering the panel with a mouse.  Like, it makes no sense. Regardless of the name, though, it's a super, super neat feature, and I'm now envious of it. Again, I wouldn't call this a full win for XFC because I also really like adaptive transparency, but still, it holds up real good. XFC also has hints of customizing the look of the panel too. You can choose any background color and you can even use a background image. Nothing that you cannot do with plasma themes, but it's nicely exposed for once. To be honest, the option being called style none feels like a self-burn if anything, but whatever. As far as floating panels go for XFC, well, you can manually make them floating using the feature that I've showcased earlier, though you still have nothing like adaptive floatingness. Still pretty cool, if you ask me. So, uploads. I haven't talked much about uploads or items, that is, the little components that you can add to the panels and move around. This is mostly because all three desktops support them, and I haven't seen significant differences. However, I want to highlight one last thing that I'm not completely sure about. Caddy plasma panels have a bit of an issue. All uploads, even third-party ones, live in the same process as plasma. This means that if any third-party plasmoid crashes, the entire plasma desktop is going down. Personally, I don't see this as much of an issue since it's extremely rare for an upload to actually crash, but it's something to keep in mind if you're trying out third-party uploads. On the other hand, according to the System76 blog post, we have that cosmic uploads do live in different processes, meaning that you'll have one process for each upload. I'm not sure if this is only for the third-party ones, or if it's one for each upload, actually. This might have possibly a certain impact on performance as well, but it's probably negligible, and it does come with added stability for the shell itself. So yes, this is another free fall point for cosmic. So to wrap this up, yes, I haven't really talked much about some nice things that plasma panels do, however, I did talk about all the most important things that people will reasonably look for in panels. And even though I haven't kept count of the points, maybe the editor did? Yes, I did. It's pretty easy to see that plasma hasn't really clearly won any comparison with either XFC nor cosmic. I still think that plasma panels are extremely powerful and really good to use, but I cannot deny either that both the cosmic and XFC projects have done great things, and we do have a lot to learn from them. And again, if you'd like me to improve plasma panels, given what I've seen other desktops do, I'd really appreciate it if you threw you through through my donation, a donation at me, and I will do my best. So thanks, everybody, for following. I hope that you still like plasma panels, even though there are clearly lacking in many areas and long life Latino. See ya.


CHAPTER 17 OF KOTTO. For more information or to volunteer, please visit LibriVox.org. Recording by Martin Giesen. Koto. Being Japanese Curios with Sundry Cobwebs. By Lafcadio Hearn. Chapter 17. Reverie. It has been said that men fear death, much as the child cries at entering the world, being unable to know what loving hands are waiting to receive it. Certainly, this comparison will not bear scientific examination, but as a happy fancy, it is beautiful, even for those to whom it can make no religious appeal whatever. Those who must believe that the individual mind dissolves with the body, and that an eternal continuance of personality could only prove an eternal misfortune. It is beautiful, I think, because it suggests in so intimate a way the hope that to large a knowledge the Absolute will reveal itself as mother-love made infinite. The imagining is oriental rather than occidental, yet it accords with a sentiment vaguely defined in most of our western creeds. Through ancient grim conceptions of the Absolute as father, there has gradually been infused some later and brighter dream of infinite tenderness, some all-transfiguring hope created by the memory of woman as mother, and the more that races evolve toward higher things, the more feminine becomes their idea of a God. Conversely, this suggestion must remind even the least believing that we know of nothing else in all the range of human experience so sacred as mother-love, nothing so well deserving the name of Divine. Mother-love alone could have enabled the delicate life of thought to unfold and to endure upon the rind of this wretched little planet. Only through that supreme unselfishness could the nobler emotions ever have found strength to blossom in the brain of man. Only by help of mother-love could the higher forms of trust in the unseen ever have been called into existence. But musings of this kind naturally lead us to ask ourselves emotional questions about the mysteries of whither and whence. Must the evolutionist think of mother-love as a merely necessary result of material affinities, the attraction of the atom for the atom? Or can he venture to assert with ancient thinkers of the East that all atomic tendencies are shaped by one eternal moral law, and that some are in themselves divine, being manifestations of the four infinite feelings? What wisdom can decide for us, and of what avail to know our highest emotions divine, since the race itself is doomed to perish? When mother-love shall have wrought its uttermost for humanity, will not even that uttermost have been in vain? At first thought indeed the inevitable dissolution must appear the blackest of imaginable tragedies, tragedy made infinite. Eventually our planet must die, its azure ghost of air will shrink and pass, its seas dry up, its very soil perish utterly, leaving only a universal waste of sand and stone, the withered corpse of a world. Still for a time this mummy will turn about the sun, but only as the dead moon wheels now across our nights, one face forever in scorching blaze, the other in icy darkness. So it will circle, blank and bald as a skull, and like a skull will it bleach and crack and crumble, ever drawing nearer and yet more near to the face of its flaming parent, to vanish suddenly at last in the cyclonic lightning of his breath. One by one the remaining planets must follow, then will the mighty star himself begin to fail, to flicker with ghastly changing colours, to crimson toward his death, and finally the monstrous, viscerate cinder of him, hurled into some colossal sun-pire, will be dissipated into vapor, more tenuous than the dream of the dream of a ghost. What then will have availed the labour of the life that was? The life effaced without one sign to mark the place of its disparition in the illimitable abyss. What then the worth of mother-love, the whole dead world of human tenderness, with its sacrifices, hopes, memories, its divine delights and divine pains, its smiles and tears and sacred caresses, its countless passionate prayers to countless banished gods. Such doubts and fears do not trouble the thinker of the East. Us they disturb chiefly because of old wrong habits of thought, and the consequent blind fear of knowing that what we have so long called soul belongs not to essence, but to form. Forms appear and vanish in perpetual succession, but the essence alone is real. Nothing real can be lost even in the dissipation of a million universes. Utter destruction, everlasting death, all such terms of fear have no correspondence to any truth but the eternal law of change. Even forms can perish only as waves pass and break. They melt but to swell anew. Nothing can be lost. In the nebulous haze of our dissolution will survive the essence of all that has ever been in human life, the units of every existence that was or is, with all their affinities, all their tendencies, all their inheritance of forces making for good or evil, all the powers amassed through myriad generations, all energies that ever shaped the strength of races, and times innumerable will these again be awed into life and thought. Transmutations there may be, changes also made by augmentation or diminution of affinities, by subtraction or addition of tendencies, for the dust of us will then have been mingled with the dust of other countless works, countless worlds and of their peoples. But nothing essential can be lost. We shall inevitably bequeath our part to the making of the future cosmos, to the substance out of which another intelligence will slowly be evolved. Even as we must have inherited something of our psychic being out of numberless worlds dissolved, so will future humanities inherit, not from us alone, but from millions of planets still existing, for the vanishing of our world can represent in the disparition of a universe but one infinitesimal detail of the quenching of thought. The peopled spheres that must share our doom will exceed for multitude the visible lights of heaven. Yet those countless solar fires, with their viewless millions of living planets, must somehow reappear. Again the wondrous cosmos, self-born as self-consumed, must resume its sidereal whirl over the deeps of the eternities, and the love that strives forever with death shall rise again through fresh infinitudes of pain to renew the everlasting battle. The light of the mother's smile will survive our sun. The thrill of her kiss will last beyond the thrilling of stars. The sweetness of her lullaby will endure in the cradle songs of worlds yet unevolved. The tenderness of her faith will quicken the fervour of prayers to be made to the hosts of another heaven, to the gods of a time beyond time. And the nectar of her breasts can never fail. That snowy stream will still flow on to nourish the life of some humanity, more perfect than our own, when the milky way that spans our night shall have vanished forever out of space. For more information or to volunteer, please visit LibriVox.org Recording by Ava'i in June 2010 Kotto, being Japanese couriers with Sanji cobwebs by Lafcadio Hearn Chapter 18 Pathological Very much do I love cats, and I suppose that I could write a large book about the different cats which I have kept in various climbs and times on both sides of the world. But this is not a book of cats, and I am writing about Tama for merely psychological reasons.  It is the cry that a cat makes only for her kittens a pure caress of tone, and I perceive that her attitude as she lies there on her side is the attitude of a cat holding something, something freshly caught. The four paws are stretched out as to grasp and the pearly talons are playing. We call her Tama, Jewel, not because of her beauty, though she is beautiful, but because Tama is a female name accorded by custom to pet cats. She was a very small tortoise shell kitten when she was first brought to me as a gift worth accepting, a cat of three colors, Mikeneko, being somewhat uncommon in Japan. In certain parts of the country, such a cat is believed to be a luck bringer and gifted with power to frighten away goblins as well as rats. Tama is now two years old. I think that she has foreign blood in her veins. She is more graceful and more slender than the ordinary Japanese cat, and she has a remarkably long tail, which, from a Japanese point of view, is her only defect. Perhaps one of her ancestors came to Japan in some Dutch or Spanish ship during the time of Ieyasu. But from whatever ancestors descended, Tama is quite a Japanese cat in her habits. For example, she eats rice. The first time that she had kittens, she proved herself an excellent mother, devoting all her strength and intelligence to the care of her little ones, until, by dint of nursing them and moiling for them, she became picturesly and ludicrously thin. She taught them how to keep clean, how to play and jump and wrestle, how to hunt. At first, of course, she gave them only her long tail to play with, but later she found them other toys. She brought them not only rats and mice, but also frogs, lizards, a bat, and one day a small lamprey, which she must have managed to catch in a neighboring rice field. After dark, I used to leave open for her a small window at the head of the stairs leading to my study, in order that she might go out to hunt by way of the kitchen roof. And one night she brought in, through that window, a big straw sandal for her kittens to play with. She found it in the fields, and she must have carried it over a wooden fence ten feet high, up the house wall to the roof of the kitchen, and then through the bars of the little window to the stairway. There she and her kittens played boisterously with it till morning, and they dirtied the stairway, for that sandal was muddy. Never was Cat more fortunate in her first maternal experience than Thama. But the next time she was not fortunate, she had gotten to the habit of visiting friends in another street at a perilous distance, and one evening, while on her way thither, she was hurt by some brutal person.  I thought that she would die also, but she recovered much more quickly than anybody could have imagined possible, though she still remains, for obvious reasons, troubled in spirit by the loss of the kittens. The memory of animals, in regard to certain forms of relative experience, is strangely weak and dim. But the organic memory of the animal, the memory of experience accumulated through countless billions of lives, is superhumanly vivid and very seldom at fault. Think of the astonishing skill with which a cat can restore the respiration of her drowned kitten. Think of her untaught ability to face a dangerous enemy seen for the first time, a venomous serpent, for example. Think of her wide acquaintance with small creatures and their ways, her medical knowledge of herbs, her capacities of strategy, whether for hunting or fighting. What she knows is really considerable, and she knows it all perfectly, or almost perfectly. But it is the knowledge of other existences. Her memory, as to the pains of the present life, is mercifully brief. Tama could not clearly remember that her kittens were dead. She knew that she ought to have had kittens, and she looked everywhere and called everywhere for them, long after they had been buried in the garden. She complained a great deal to her friends, and she made me open all the cupboards and closets over and over again to prove to her that the kittens were not in the house. At last she was able to convince herself that it was useless to look for them anymore. But she plays with them in dreams and coos to them and catches for them small shadowy things, perhaps even brings to them through some dim window of memory a sandal of ghostly straw. Chapter 19 In the dead of the night Black, chill and still, so black, so still, that I touch myself to find out whether I have yet a body. Then I grope about me to make sure that I am not under the earth, buried forever beyond the reach of light and sound. O'clock strikes three. I shall see the sun again. Once again, at least, possibly several thousand times. But there will come a night never to be broken by any dawn, a stillness never to be broken by any sound. This is certain, as certain as the fact that I exist. Nothing else is equally certain. Reason deludes, feeling deludes, all the senses delude. But there is no delusion whatever in the certain knowledge of that night to come. Doubt the reality of substance, the reality of ghost, the faith of man, the gods. Doubt right and wrong, friendship and love, the existence of beauty, the existence of horror. There will always remain one thing impossible to doubt, one infinite, blind black certainty. The same darkness for all, for the eyes of creatures and the eyes of heaven. The same doom for all, act and man, and hill and city, races and worlds, suns and galaxies, inevitable dissolution, desperation and oblivion. And vain all human striving not to remember, not to think. The veil that old faith wove to hide the void has been rend forever away and she always naked before us and destruction has no covering. So surely as I believe that I exist, even so surely must I believe that I shall cease to exist, which is horror. But must I believe that I really exist? In the moment of that self questioning the darkness stood about me as a wall and spoke I am only the shadow I shall pass but the reality will come and will not pass. I am only the shadow in me there are lights the glimmering of a hundred millions of suns and in me there are voices with the coming of the reality there will be no more lights nor any voice nor any rising nor any hope but far above you there will still be sun for many a million years and warmth and youth and love and joy vast Asia of sky and sea fragrance of summer bloom shrillings in grass and grove flood of shadows and flicker of light laughter of waters and laughter of girls blackness and silence for you and cold blind creepings I made reply of thoughts like this I am now afraid it is only because I have been startled out of sleep when all my brain awakens I shall not be afraid for this fear is brute fear only the deep and dim primordial fear bequeathed me from the million ages of the life of instinct already it is passing I can begin to think of deaths as dreamless rest a sleep with no sensation of either joy or pain the darkness whispered what is sensation and I could not answer and the gloom took weight and pressed upon me and said you do not know what is sensation how then can you say whether there will or will not be pain for the dust of you the molecules of your body the atoms of your soul atoms what are they again I could make no answer and the weight of the gloom walks greater a weight of pyramids and the whisper hissed their repulsions their attractions the awful clingings of them and the leapings what are these passions of lives burned out furies of insatiable desire frances of everlasting hate madnesses of never ending torment you do not know but you say that there will be no more pain then I cried out to the mocha I am awake awake fully awake I have ceased to fear I remember all that I am is all that I have been before the beginnings of time I was beyond the uttermost circling of the eternities I shall endure in myriad million forms I but seem to pass as form I am only wave as essence I am sea sea without show I am and doubt and fear and pain are but duskings that fleet on the face of my depth asleep I behold the illusions of time but awaken I know myself timeless one with the life that has neither form nor name yet also one with all that begins and ends even the grave and the maker of graves the corpse and the eater of corpses a sparrow tweeted from the roof another responded shapes of things began to define in a soft gray glimmering and the gloom slowly lightened murmurs of the city's awakening came to my ears and grew and multiplied and the dimness flushed then rose the beautiful and holy sun the mighty quickener the mighty petrifier symbols a blime of that infinite life whose forces are also mine end of chapter 19 Libraryvox.org Recorded by David Barnes Cotto being Japanese Curios with Sondry Cobwebs by Lafcadio Hearn Chapter 20 Kusahibari His cage is exactly two Japanese inches high and one inch and a half wide its tiny wooden door turning upon a pivot will scarcely admit the tip of my little finger but he has plenty of room in that cage room to walk and jump and fly for he is so small that you must look very carefully through the brown gore's sides of it in order to catch a glimpse of him I have always to turn the cage round and round several times in a good light before I can discover his whereabouts and then I usually find him resting in one of the upper corners clinging upside down to his ceiling of gore's imagine a cricket about the size of an ordinary mosquito with a pair of antennae much longer than his own body and so fine that you can distinguish them only against the light Kusahibari or grasslark is the Japanese name of him and he is worth in the market exactly twelve cents that is to say very much more than his weight in gold twelve cents for such a nat-like thing by day he sleeps or meditates except while occupied with the slice of fresh egg plant or cucumber which must be poked into his cage every morning to keep him clean and well fed is somewhat troublesome could you see him you would think it absurd to take any pains for the sake of a creature so ridiculously small but always at sunset the infinitesimal soul of him awakens then the room begins to fill with a delicate and ghostly music of indescribable sweetness a thin, thin silvery rippling and trilling as of tiniest electric bells as the darkness deepens the sound becomes sweeter sometimes swelling till the whole house seems to vibrate with the elfish resonance sometimes thinning down into the faintest imaginable thread of a voice but loud or low it keeps a penetrating quality that is weird all night the atomy thus sings he ceases only when the temple bell proclaims the hour of dawn now this tiny song is a song of love vague love of the unseen and unknown it is quite impossible that he should ever have seen or known in this present existence of his not even his ancestors for many generations back could have known anything of the nightlife of the fields or the amorous value of song they were born of eggs hatched in a jar of clay in the shop of some insect merchant and they dwelt thereafter only in cages but he sings the song of his race as it was sung a myriad years ago and as faultlessly as if he understood the exact significance of every note of course he did not learn the song it is a song of organic memory deep dim memory of other quintillions of lives when the ghost of him shrilled at nights from the dewy grasses of the hills then that song brought him love and death he has forgotten all about death but he remembers the love and therefore he sings now for the bride that will never come so that his longing is unconsciously retrospective he cries to the dust of the past he calls to the silence and the gods for the return of time human lovers do very much the same thing without knowing it they call their illusion an ideal and their ideal is after all a mere shadowing of race experience a phantom of organic memory the living present has very little to do with it perhaps this atomy also has an ideal or at least the rudiment of an ideal but in any event the tiny desire must utter its plaint in vain not altogether mine I had been warned that if the creature were mated he would cease to sing and would speedily die but night after night the plaintive sweet unanswered trilling touched me like a reproach became at last an obsession an affliction a torment of conscience and I tried to buy a female it was too late in the season there were no more ready for sale either males or females the insect merchant laughed and said he ought to have died about the twentieth day of the ninth month it was already the second day of the tenth month but the insect merchant did not know that I have a good stove in my study and keep the temperature at above seventy-five degrees fahrenheit wherefore my grasslark still sings at the close of the eleventh month and I hope to keep him alive until the period of greatest cold however the rest of his generation are probably dead neither for love nor money could I now find him a mate and were I to set him free in order that he might make the search for himself he could not possibly live through a single night even if fortunate enough to escape by day the multitude of his natural enemies in the garden ants, centipedes and ghastly earth spiders last evening the twenty-ninth of the eleventh month an odd feeling came to me as I sat at my desk a sense of emptiness in the room then I became aware that my grasslark was silent contrary to his won't I went to the silent cage and found him lying dead beside a dried up lump of eggplant as grey and hard as a stone evidently he'd not been fed for three or four days but only the night before his death he'd been singing wonderfully so that I foolishly imagined him to be more than usually contented my student Aki who loves insects used to feed him but Aki had gone into the country for a week's holiday and the duty of caring for the grasslark had devolved upon Hannah, the housemaid she is not sympathetic Hannah, the housemaid she says that she did not forget the mite but there was no more eggplant and she had never thought of substituting a slice of onion or of cucumber I spoke words of reproof to Hannah, the housemaid and she dutifully expressed contrition but the fairy music has stopped and the stillness reproaches and the room is cold in spite of the stove absurd I have made a good girl unhappy because of an insect half the size of a barley grain the quenching of that infinitesimal life troubles me more than I could have believed possible of course the mere habit of thinking about a creature's wants even the wants of a cricket may create by insensible degrees an imaginative interest an attachment of which one becomes conscious only when the relation is broken besides I had felt so much in the hush of the night the charm of the delicate voice telling of one minute existence dependent upon my will and selfish pleasure as upon the favour of a god telling me also that the atom of ghost in the tiny cage and the atom of ghost within myself were forever but one and the same in the deeps of the vast of being and then to think of the little creature hungering and thirsting night after night and day after day while the thoughts of his guardian deity were turned to the weaving of dreams how bravely nevertheless he sang on to the very end an atrocious end for he had eaten his own legs may the gods forgive us all especially Hannah the housemaid yet after all to devour one's own legs for hunger is not the worst that can happen to a being cursed with the gift of song there are human crickets who must eat their own hearts in order to sing end of chapter 20 Kusahibadi Chapter 21 of Koto This is a LibriVox recording The LibriVox recordings are in the public domain For more information or to volunteer please visit LibriVox.org Recording by Scott Carpenter Koto being Japanese curios with Sundry Kobwebs by Lofkario Hearn Chapter 21 The Eater of Dreams Mijikayo-ya Baku no yumeku Hima monashi Alas how short this night of ours the Baku will not even have time to eat our dreams Old Japanese love song The name of the creature is Baku or shirokina katsukami and its particular function is the eating of dreams It is variously represented and described An ancient book in my possession states that the male Baku has the body of a horse the face of a lion the trunk and tusks of an elephant the rhinoceros the tail of a cow and the feet of a tiger The female Baku is said to differ greatly in shape from the male but the difference is not clearly set forth In the time of the old Chinese learning pictures of the Baku used to be hung up in Japanese houses such pictures being supposed to exert the same beneficent power as the creature itself My ancient book contains this legend about the custom of seiroku It is declared that Kote while hunting on the eastern coast once met with a Baku having the body of an animal but speaking like a man Kote said since the world is quiet and at peace why should we still see goblins if a Baku be needed to extinguish evil sprites then it were better to have a picture of the Baku suspended to the wall of one's house thereafter even though some evil wonder should appear it could do no harm then there is given a long list of evil wonders and the signs of their presence when the hen lays a soft egg the demon's name is Taifu when snakes appear entwined together the demon's name is Jinzu when dogs go with their ears turned back the demon's name is Taiyou when the fox speaks with the voice of a man the demon's name is Guaishu when blood appears on the clothes of men the demon's name is Yuki when the rice pot speaks with a human voice the demon's name is Kanjo when the dream of the night is an evil dream the demon's name is Iringetsu and the old book further observes whenever any such evil marvel happens let the name of the Baku be invoked then the evil sprite will immediately sink three feet under the ground but on the subject of evil wonders I do not feel qualified to discourse it belongs to the unexplored and appalling world of Chinese demonology and it has really very little to do with the subject of the Baku in Japan the Japanese Baku is commonly known only as the Eater of Dreams and the most remarkable fact in relation to the cult of the creature is that the Chinese character representing its name used to be put in gold upon the lacquered wooden pillows of lords and princes by the virtue and power of this character on the pillow the sleeper was thought to be protected from evil dreams it is rather difficult to find such a pillow today even pictures of the Baku or Hakutaku as it is sometimes called have become very rare but the old invocation to the Baku still survives in common parlance when you awake from a nightmare or from any unlucky dream you should quickly repeat that invocation three times then the Baku will eat the dream and will change the misfortune or the fear into good fortune and gladness it was on a very sultry night during the period of greatest heat that I last saw the Baku I had just awakened out of misery and the hour was the hour of the ox and the Baku came in through the window to ask have you anything for me to eat I gratefully made answer assuredly listen good Baku to this dream of mine I was standing in some great white-walled room where lamps were burning but I cast no shadow upon the naked floor of that room and there upon an iron bed I saw my own dead body how I had come to die and when I had died I could not remember women were sitting near the bed six or seven and I did not know any of them they were neither young nor old and all were dressed in black watchers I took them to be they sat motionless and silent there was no sound in the place in the same moment I became aware of something nameless in the atmosphere of the room a heaviness that weighed upon the will some viewless numbing power that was slowly growing then the watchers began to watch each other stealthily and I knew that they were afraid soundlessly one rose up and left the room another followed then another so one by one and lightly as shadows they all went out alone with the corpse of myself the lamp still burned clearly but the terror in the air was thickening the watchers had stolen away almost as soon as they began to feel it but I believed that there was yet time to escape I thought that I could safely delay a moment longer a monstrous curiosity obliged me to remain I wanted to look at my own body to examine it closely I approached it and I wondered because it seemed to me very long unnaturally long then I thought that I saw one eyelid quiver but the appearance of motion might have been caused by the trembling of a lamp flame I stooped to look slowly and very cautiously because I was afraid that the eyes might open it is myself I thought as I bent down and yet it is growing queer the face appeared to be lengthening it is not myself I thought again as I stooped still lower and yet it cannot be any other and I became much more afraid unspeakably afraid that the eyes would open they opened horribly they opened and that thing sprang sprang from the bed at me and fastened upon me moaning and gnawing and rending with what madness of terror did I strive against it but the eyes of it and the moans of it and the touch of it sickened and all my being seemed about to burst a thunder and a frenzy of loathing when I knew not how I found in my hand an axe and I struck with the axe I clove, I crushed, I braided the moaner until they lay before me only a shapeless, hideous reeking mass the abominable ruin of myself baku kurai baku kurai devour o baku devour the dream nay, made answer the baku I never eat lucky dreams that is a very lucky dream a most fortunate dream the axe, yes the axe of the excellent law by which the monster of self is utterly destroyed the best kind of a dream my friend I believe in the teaching of the Buddha and the baku went out of the window I looked after him and I beheld him fleeing over the miles of moonlit roofs passing from housetop to housetop with amazing soundless leaps like a great cat end of chapter 21 end of koto being Japanese curios with sundry cobwebs by lafcadio herne


So what's up? Who I got on the phone with me? Come on man, I know you're in. So um, so tell us how you feeling? I'm good, I'm good, I'm good. I'm trying to get back out there to y'all. I'm going to Bob, I miss y'all. Yeah, so Roman said you could be coming home soon. Yeah, real soon, real soon, real soon. I'd be out here real soon. Real soon, real soon. Okay, so from RPT, you know, Kenzo doing that thing, anybody else you see doing anything from that side? Yeah, I see my little girl, my little girl and I, it's a lot of people doing anything right now. I know how to shop cheese, I see stunner, mastic, all my clothes, all my clothes. We're doing anything right now. Yeah, we need to get back out here, though. Okay, and then um, how we getting new music? That's what everybody wants to know. Like, sure, like sure, yes, yes, yes, I just, I just told them I need to drop something soon, I need to drop something before I come home. I need to drop something before I come home. So, are you going to drop something before you come home? Yeah, for sure, for sure, for sure. Are you coming next month? Are you going to come home? Okay, you know what song yet or not? No, I don't know what song yet, I'm still debating, I'm still debating. Okay, and then, I don't know if you want to stay here or you want to wait till you come home, but if people want to know, are you signed or are you still independent? No, no, no, no, I'm still independent, I'm still independent. No, I think no, I'm still independent. Okay.   I love y'all, I love y'all. Be home soon, I'll be home soon. You can turn up, bro, I'll be home soon to turn the city up.