Our third speaker is Polisa Anderson. Thank you Caroline and my co-panelists. Thank you very much Kylie, Bella, Lisa and Akotika for welcoming us so brilliantly. Now my story is a parallel one to the Indigenous story. I'm Polisa Anderson. I'm a first-generation organic produce grower and a second-generation restaurateur. For the longest time, I have this recurring sequence in my mind's eye of being taken to the forest somewhere in the deep northern part of Thailand as a very young child, two or three years old, to forage for white ant larvae. I remember being lifted off the ground while the nest came down and the larvae was delicately plucked out, someone whispered in my ear that this had to be harvested now because it was the season. Now that seems like a very complex memory for a child so young and I always thought for the longest time that I'd imagined it, but recently at a family gathering it was confirmed to me by an aunt of marriage. She'd taken me into the forest, close to a village in Rul Rul Lampang which is near Chiang Mai, northern Thailand. This memory is for me so poignant because while my mother was not there, she's here now, it felt like a very maternal embrace. The texture of the ant's larvae in my mouth as I was fed this warm, nutritious, delicious creamy food and being held off the ground to stay safe. Where was my mother? Well, this is the crux of the story. She was here in Australia and I'm really only talking to you today because of her and her story. My mother Amy was born to Chinese immigrant parents who sought political asylum in Bangkok from the communist regime of the 1940s. Her parents established themselves very quickly in Bangkok, my grandfather, an engineer at a textile mill and my grandmother also worked for the same mill. With both parents working so hard, she was entrusted to an elderly Thai caretaker who took her home to a village and spent most of her toddler years until she was of school age being reared in the very traditional Thai way of life. Temple fairs, feeding stray dogs and feeding, sorry, giving arms to monks every morning, swimming in the river and eating a very Thai agrarian-based diet. When she started school, the loss of that idyllic way of life scored a deep mark within her and in some ways to this day, I think that is what she is constantly trying to recreate, that way of giving and feeding and the constant lookout for sanook, which means fun. My mother migrated to Australia from Bangkok at the age of 26 in 1984. Why did she choose Australia? Well, she had one brother in the States and one brother here in Sydney and she chose Australia, I think, for the proximity and she probably liked her younger brother better. And because the other thing was she didn't have to learn to drive on the other side of the road. Now, life was really complicated for her already.  My brother Pat and I were left with our paternal grandparents in Bangkok such as the fate and sad, sad fate of many working immigrant parents who grow abroad to work just to be separated from their children. In our case, we were very lucky. It only lasted for two years. She was incredibly industrious, working multiple jobs, cleaning, sewing and eventually getting work at a renowned Thai restaurant in Sydney where his owner found her so indispensable in the kitchen that he sponsored her. Now, my mother has an amazing attitude for hard work. Despite coming from a solid middle-class background, she had gone to a private Catholic girl's school where she was taught by English nuns. When I ask her what she remembers of this period in her life, she says, well, as a five-year-old looking up and thinking how narrow their nostrils are. So to hear her tell of her struggles, her initial struggles in Sydney, just breaks my heart. She cleaned other people's homes. She sewed till her fingers bled. She'd never sewn anything in her life before. In Thailand, she'd grown up with help. She couldn't speak much English, so it was totally voiceless when racist insults were hurled her way. But her resolve was helped by the many, many kind people she came across, and there were very, very many. She endured all this so that my brother and I could come to be with her in Sydney and as every parent she hoped to give us a better life. Every single dollar she made, she saved and she saved and saved until she could open her own restaurant, which she did in 1989. She opened a fine dining establishment with a business partner who eventually left and became a flight attendant after two years. Chat Thai darling, that's how, you know, successful it was. Chat Thai darling, her shut at the store after only two years and having that initial failure put her in good stead to do things differently the next time around. In her heart, she'd always wanted to do a fast, casual diner type of restaurant. So, being ever practical, she went to work for McDonald's. She absorbed everything she could about the McDonald's management system in one year. She was so brilliant that the owners chose her to be in the photo op that appeared in the local daily in the inaugural opening of the drive-thru. I still have that picture. When she opened Chat Thai again, the food she cooked was of the time, namely very suited to what Australians knew about Thai food, not much. Except for the standard hallmarks of the Thai menu. A lot of it had to do with availability of Southeast Asian ingredients. So every weekend, she'd bundle us up in the car to make the 90-minute trek out to Cabra Matta, the centre of the Southeast Asian diaspora of the time. There, it was like entering another country. A bustling marketplace with ladies lining the plaza, selling tubs of homemade sauces and desserts, seedlings of edible exotic flora. Massive, massive bundles of herbs, unlike the $2 worth bundles, that they'd grown and harvested themselves. And awful, awful at the butchers. So while she raced around, buying her weekly quota for restaurant and home, I sat outside, minding the bags and eating dumplings. She was nostalgic for gutsy, spicy, and deep fermented layers of flavour, which ironically was what she and her one employee at the time would cook for staff meal. At that point, her staff included herself, her cousin, her one employee, and her children on the weekend. You'll be glad to know that that one employee, Nanoy, after 28 years, is still in the Chattai family. So this leads to my part of the story. At the ripe old age of nine, I had been initiated already into restaurant craft for almost two years. I started off peeling garlic and prepping herbs with my little nimble fingers and progressed on to chopping onions and shelling and deveining prawns. Literally doing all the fun jobs that were fun for about the first minute. My mother was excellent, is excellent at reverse psychology, as she will probably explain to you today, but how she got us to work. She essentially guilt tripped us into it. We were hers to shape, and shape she did. There wasn't a single station in the restaurant that we didn't know how to work. Undoubtedly, we learnt more maths there than at primary school. I learnt the meaning of true grit one service when at the age of nine, one Friday night, naturally, and we were under the pump. I ran front of house, there were eight tables, six inside, two outside, and I came in rushing in, demanding something from the kitchen, a main perhaps and probably most likely giving lip or probably where to stick it. Well, I felt affronted and went and soaked by the back stairs for all two minutes and thinking, oh, how do I get out of here? How do I run away from this place? Took a deep breath, and much straight back out to my table thinking of my waiting diners. The lesson was invaluable, as of course many lessons gleaned from the hospitality industry are. The humility, discipline and resilience needed to face the ebbs and flow of life can all be surely learnt from working in a restaurant. After studying liberal arts, I studied and worked and travelled and lived abroad for ten years, returning after the birth of my second son, sorry, my second child, who was a son, eight years ago. My mother had constantly kept up her offer of coming back to rejoin the family business, which by then had grown to four eateries around Sydney. She had grown the business organically and slowly. Her ethos, one of many, had grown low margins. All the while, she had massed a faithful clientele and an even more loyal body of staff. Her menu had evolved to something she was really proud of, true regional Thai dishes, alongside the more popular, often ordered corporates. The attitude was, we couldn't change palates and habits over the night, but we might as well try. Her kitchens became a collaboration between different stratas of people who in Thailand would never have worked together since being friends. Sons of farmers, blue collar workers, daughters of lawyers, people with kitchen experience and people without kitchen experience all had to band together day after day to carry each other through. LGBTQI existed in our restaurants before it was even a thing. Growing up in a restaurant, growing up in that environment, it didn't even occur to me that it was different. Something wonderful also happened in our kitchen. She highlighted everyone's ability to contribute to the menu. If you were the dishwasher and your mum had taught you how to make wedge up with all the offal and the innards, please proceed to the stove. If anyone had an opinion on how a dish could be made better than by all means, speak up. Nothing was too sacred that it couldn't be improved on by using different techniques or better ingredients to make an approach to running the creative aspect of a kitchen influenced me greatly. Another aspect of how our business is run differently is my mother's familial style. It sounds cheesy, but it is run like a big family kitchen, total chaos. By spending time with our people outside of work and also getting to know their families in Australia and Thailand, we cement a real bond. Their struggles are our struggles. Their victories and joys ours. In my opinion, it is not necessarily a feminine approach. It is the only one which my mum thought to operate because we cooked Thai food and that system of work reflected the Thai social mores. Another Thai social more is the deep respect for elders. Obviously when I started working in my mother's kitchen, I was the youngest and I called everyone by the elder prefix of pi na pa lung yai, so elder sibling, aunt, uncle, grandmother. As I've aged, I've risen through these ranks and it always still catches me by surprise to hear my name with an elder prefix attached to it. As a youngster naturally, I couldn't wait to fly the coop. I wanted to prove myself independent of this Thai restaurant universe which was my world. For a time, I rejected the language and though I found much beauty in the culture, I felt myself outside of it. It's the natural state of third culture kids like myself to feel alienated. I had the light bulb moment, no matter who you are, you're bound to feel that sense of loneliness and isolation. It's all part of the human experience, right? There's only one me and one you. So all that time I lived abroad. I couldn't escape my mother's phone calls asking for my help to translate this or that, contracts, menu items, for that was my role. Daughter equals translator, equals interpreter. Fixer. I couldn't even escape Chat Thai. I kid you not. In the gift store of the Prado in Madrid, the sales lady noticed my Australian accent and mentioned that she dreamily had done a student exchange and lived in Manly and of course that had led on to, and my favourite place to eat was Chat Thai. Famed for its student friendly prices. And everywhere I went, Hong Kong, London, New York, Tokyo, it was all the same. The coincidence was too much. I kept meeting people who were fans of Chat Thai and all had a fond memory of my mother and a kind word to say about her. Like what? How is it possible that so many people had eaten at our restaurants? We were just a little family-run business in the Lord's evening. How on earth do I feel those shoes? Or rather, how do I carve a role for myself within it? That question has led to me and my family down this path for our restaurants. The next step to growing the business was literally to start growing the food to become vertically integrated. My mother knew me well when she enticed me back to the country. She said, well, when you come back here you can have a garden, grow your own food knowing how much I love gardening. She was, I was living in Tokyo at the time with a young family and that was really tempting. Little did I know that the garden would be 107 acres. When I did come back we started doing the farm business, visiting our existing growers and seeking new farmers to work with up and down the Australian eastern seaboard all the way up to Darwin. What we found were small-scale producers, many of them Thai, who really were growing it for themselves to cook, but soon found that there was a market for it, market for it, among Southeast Asian restaurateurs and supermarkets and diaspora living in the city. For the scale we needed, we knew it was only a matter of time. We bought a farm in Arakul country that was known as Byron Shire three years ago. The place of plenty as it is known is at the foothills of a chain of dormant volcanic overflow of which many indigenous foods originated like the macadamia nut, finger limes, various species of nating fruit trees and medicinal herbs. And while still in New South Wales it's very close to the Queensland border and so it has a subtropical microclimate, lush terracotta, loamy, basalt based soil. The soil is so fertile, practically cheating you're right. We were able to harvest our first batch of herbs and vegetables in less than six months. We took another six months before that to rehabilitate the land after it had been overgrazed when we bought it. Becoming a producer has made me well aware of all the discrepancies and shortfalls between producer and end of line consumer. We were completely unprepared for how the shock that came with how much it cost to produce organic food with integrity uninterrupted by hormone stimulators to be completely pesticide and herbicide free, implementing responsible land stewardship importantly growing in a way that promotes soil biodiversity mindful management of the ecology. With that knowledge we've come to understand that part of the reason why people take up this type of farming or food production is purely for the lifestyle. No one's doing it to get rich. So in this sense it doesn't wonder at all far from what made my mother start Chat Thai and to keep it going. It is the knowledge that she's affecting the many and not the few. We serve up food that seems to have been growing in our backyard for your pleasure. Not unlike if you were to drop over to auntie's place on the way home from work and she's just going to pop on the back there and you know put a snack together for you and boom suddenly you've got a banquet. How is it possible that she's all out of her garden? That's how I've come to see what we're doing. We grow a diverse heirloom and lesser known varieties that is in our backyard and not commercial varieties that get grown for shelf life or popularity. That's the true beauty of our farm. We are able to select varieties and for flavours my mother grew up with in the happiest time when she lived with her Yai, her beloved Ketai caretaker. That's how she remembers Thai food and perhaps that's what I've been seeking all this time. A way, a wormhole to get back to the flavour, the white and salave. Something wild, natural and free. Thank you.


Hey, welcome. My name is Thijs. If you want to join, I'm doing a little demo later on, so if you want to join that and also, like, look at the code I'll be talking about, please clone this repository. So today I'm going to talk about how to do concurrency in Ruby, using just very simple stuff from the standard library. So I work on a monitoring product for Ruby called AppSignal. And we support a lot of different types of web servers and tools, which kind of forced me to learn about all the different ways you can do concurrency in Ruby. And then I realized that years before, this always sort of sounded like an intimidating subject, and I felt like I didn't really understand what was going on, but it was actually quite a bit easier than I thought. So today I'm here to share some of these insights with you. So in general, there's a few exceptions to this, but for simplicity's sake, we're going to be talking about these three main ways of doing concurrency. So you can either run multiple processes, you can run multiple threads, or you can run an event loop and have that kind of fake concurrency in a sense. So you're probably familiar with these three web servers. So they all use one of these models with their open downsides. So we're going to try and do this, discuss this subject by building a very simple chat server that's kind of like Slack. So I implemented a little chat server in Ruby in these three different ways. So my colleague Roy over there is already logged into it, hopefully. Well, of course, it's not working. Hi, Roy. Ah, it's working. So, well, here's our very minimalistic Slack. I'm afraid we won't be getting millions of VC funding for this, but at least it worked. So we'll start with discussing the chat client. So this file is called client.rb if you checked out the repository. And this uses the just basic networking stuff from the Ruby standard library to make a connection. So it starts by requiring socket, which brings in all this network logic. And then it opens a TCP connection to a certain address. And then it boots up a little thread that just asks the client for incoming data. So basically anything the server sends back to the client will get written out to the command line. And finally, it just listens on the command line. That's this scdin.get. Basically, just wait for you to type something, press enter, and then it will trigger that loop. And then it puts that on the client. So, and that means that it gets written back to the server. So the server receives this data and the server can write data back to the client. And the client is able to either get user input from you or write stuff that the server wrote back to the command line. And basically this is a full chat client. I'm just sorry to say it doesn't support any animated GIFs. So as discussed, there's three ways to do this in Ruby. And the first and most simple way in a sense is to use multiple processes. So this is how Unicorn works. What happens is that there's one master process that gets started by your system. And whenever some work needs to be done, that forks into a child process. And that child process can do some work and then might get killed again or will live for a little bit longer. And this worker process does the actual work. And the master process kind of manages these child processes. And if you would look at this on your activity monitor on your Mac or on top on the server, it would look something like this. So you've got a master and a few Unicorn workers. And you could actually kill one of these workers or just let it crash. And then the master process will make sure that a new one gets spawned. So this is pretty resilient architecture. So what does this look like in Ruby code? We'll first start with actually starting the server. So this piece of code is the same for all the examples. Basically, we started TCP server on a certain port. And that from that moment on, it just listened for new incoming connections. And since we're using multiple processes here, these processes have a completely different namespace. So anytime you, if you modify some variable in one of the processes, this won't influence the other ones at all because they're actually completely isolated by the operating system. So that's why we need a way to communicate between those. Because if we receive some chat message on a process that's handling one connection, we need to be able to write it to all these other connections that are actually different processes. So I've simplified this a little bit. You can see the full code in the examples. What it comes down to is that we use a pipe. You might have seen that on a command line. If you, you can use this to rep through a stuff, for example. What happens is that a pipe is just a stream of data from one process to the other. So if you open a pipe and you write from process one, the data will be listenable from process two. So we just set up this communication. The details are in the examples. And that will magically make sure that all the other processes also get all the chat messages. And then we get to the management part of how this works. So this is very similar to what Unicorn would do. So we start a loop. And we try to accept a new connection from the server. So server.except just waits for somebody to connect. And whenever this happens, it's the next iteration of the loop. Then we set up a pipe so we can write between the new process and the master. And we add this pipe to the list of processes in the master to make sure that we can also write back to the child process. And then there's a little magical word that does a lot of stuff which is fork. And what fork does is it just makes a complete copy of the process exactly as it is at that moment. So basically the moment you call fork, anything that happens within the do and block is the new process. And anything behind it is the old process. So the old one is still there. And there's a new one which is just a complete clone which starts doing work in like the moment do ends. Like anything inside of do and end. Which this is actually quite a hard concept to wrap your head around. I think you really have to try this out a few times on your own machine to really get it. I know I didn't really get any of the explanations. I really had to see it for myself to be able to understand it. So now what happened is we have a child process. And this child process is aware of which stream it's connected to. So next up, we can actually do some chat logic. So the first thing we do is read the first line from the socket and just assume that's the nickname. That's kind of the protocol of our chat server. The client just writes out your nickname as the first line.  And then what happens is this is not line 31 is again simplified. This starts with a little thread that writes incoming messages back to the client. So I'm sorry to say we do actually need a thread in a multi-process example to make it all work. Otherwise, you wouldn't be able to really implement the whole thing. And then it just basically waits for you to type something. So there's a while loop at the bottom. It tries to read a line of text from the socket. And writes back this line of text back to the pipe. And the pipe writes it back to the master process. So it's quite a few moving parts. So in this case, doing it with multi-process is actually a bit more code than the other versions. Sorry, I skipped one thing. So what happens next is that the master process can write this text message back to all the children. And the children can write it back to your terminal. And we will see how this works in the demo, like how this operates in reality in the demo at the end of the talk. So there's a few good things about multi-process concurrency. So one thing is that you can basically forget that such a thing as concurrency exists because anything that happens in the process is just executed in single thread. And there's no way, like, any thread safety issues can arise. And the next good thing is that workers can crash. So, for example, GitHub really likes this model. So both Unicorn and Rescue, which were written by them, use this model because they do a lot of call-outs to the Git command on the command line. And that has a tendency to use a lot of memory in crash. So they would have issues with a threaded model because the thread could bring down the entire process. And in this case, the master will just reboot anything that crashes. And the downside is that it uses a lot of resources. So any time you want to do anything that happens at the same time, you need multiple processes which use memory all over the place. So it's actually a very poor choice for a chat server. But it does work, as we'll see in a bit, which brings us to the next model, which is multi-threading, which makes a lot more sense for a chat application, actually. What happens here is that you have a single process. And within this process, you can boot threads that do work. But they still share all the memory. So if you mutate something in memory in one thread, it will also be different in another thread. And that looks something like this. So, again, we have exactly the same TCP server that gets opened. But then things are a bit different. So what we do here is we're basically using this messages array as a database. So anytime a new message comes in, we just put it into this array so we can store it and send it to other people. But if multiple threads would be reading and writing to this array at the same time, then it might actually end up coming into an inconsistent state. Because one could be reading stuff while at the meantime another one is inserting stuff. And maybe then a message wouldn't be written to our clients, for example. And that's why we need a mutex. So a mutex is basically like a traffic light. So a thread can lock a mutex. And basically tell a mutex, I'm working with this data at the moment. And then when it releases the lock, then another thread can lock it and also work with the data. But they can't do it at the same time. So this enforces that your data stays in a consistent state. The downside, of course, is that if you have a lot of locking, then the whole thing might actually be just as slow as a single process application. Because if all the threads kind of like end up just doing work one by one instead of concurrently, then you still don't have a concurrent system. So if you hear what we're locking, also in a database context, it's kind of like how this works too. So next up, we do the same server.except call. So again, we're waiting for somebody connected to server. But instead of forking, we're actually starting a thread. So anything that happens within the do and the end block is running in a separate thread within the same process, which is running sort of independently of the other threads. So again, we're reading the nickname from the socket and we're writing something back to the socket. And here it's slightly different. So instead of having to set up all these pipes, we run a little thread again that just sends incoming messages back to the client and reads messages from the client. If you look in the examples, you will see the implementation of these two methods. They're also for simplicity sake. I didn't add that here. And when a new message comes in, then we basically just push it onto this messages array, which is kind of like our mock database. So we call mutex.synchronize, which locks the mutex and makes sure that only R thread is currently doing anything with this messages array. And then we just push a new message onto it. So in reality, you will probably store this in Redis or whatever to make sure it will survive a crash of the process. And next up, we write these messages back to every client every 200 milliseconds. So again, we have to log and then it collects all the messages that have to be sent. So we're storing a sent until timestamp. Yeah. Yeah, for sure. Yeah. So that's a good question. A mutex can deadlock. So if you, it basically means that if you lock something, but never release the lock, or you lock something and then you lock something else, and these two locks are kind of like waiting for each other, then basically your process will never continue doing any work. So this is also a risk of using a mutex. And these kind of issues are the reason why people in general say that the programming using threads is pretty hard because you have to be aware of all these risks and and and not do any stupid stuff.  So yeah, that's kind of a problem. So we got the messages we want to send and we just write them out to the socket with the soccer dot pooch line. And we sleep for a little bit. So this is kind of you can already sort of see the Achilles heel of the system. Maybe because we have to lock.  So if we have a lot of throughput and probably the percentage of time that the whole that messages are a is locked will get higher and higher and maybe at some point it will be so high that we won't actually be able to send out messages as fast as they come in. But I don't think at the moment we're probably not not going to reset limits. I don't see that many people with a laptop app. And it will look something like this in your process manager. So there's a single process with a single process ID. And it's just running a few threads. So there's there's another thing to think about when you use threads and Ruby, which is the global interpreter lock. And the global interpreter lock is this thing that's specific to Ruby. It's kind of like it's, it's kind of a relic from the past, which is still at the moment still in the MRI version is still present. So in Ruby, I rely on Ruby code cannot be executed in multiple threads at the same time. So for example, if you run a few threads, and you would, you would, you would store stuff in in hash, then, or do some calculations in different threads, then actually they're just running a one by one instead of instead of concurrently. And the only exception to that is IO. So if you, if you write to a socket or you write to disk or you read to disk from disk, then, then, then the lock actually won't be active. And this is the reason why why using threads in Ruby is often useful, because especially in like a web context, or you do networking, of course, most time is spent doing a call to debate database and getting it back. And in the meantime, Ruby can do other stuff. So in reality, it's still quite useful, even though there is this lock present. And another thing is threat safety, which we already discussed a little bit just now, there's a risk of deadlocks you, if you're not careful, then you can mutate things at the same time, or, or, and then your counters are totally off, for example. So it's, it's not really for the faint of heart to, in Ruby, at least to, to, to do this you, you do really have to know what you're doing. So the positive side of this is that it uses a lot of memory per connection than multiprocess. And you can share data easily. So you don't need to set up all this, this communication between the processes. You can basically just have an array that's stored in central location. And the whole thing will just work. Well, and you do have to make sure that your code is thread safe. And you, and it doesn't make any sense for CPU intensive operations, since these will only, will only run in a single thread at the same time anyway, which is rare in, in web plans. So it's usually not that much of an issue. And I skipped one. So if, if a thread crashes, there is a possibility that the whole process crashes. And then basically the whole thing is gone, because there's not, there's no master process making sure that it gets started again. And then we get to the, to the final way of the concurrency ruby, which is an event loop. And the funny thing about an event loop is that it's, it's not actually concurrent. It's, it's the trick about it is that it's so fine grained that it's kind of like a magic trick. It, it seems to be very concurrent, but actually it's only doing one thing at the same time. And we'll, we'll get to that in a bit. And it uses very little memory per, per connection. So it's, it's a good choice for something like a jet client in general. And an event loop looks, looks something like this. So it all starts with the operating system. So the operating system, of course, knows like what kind of network connections are open, and what's going on. And you can ask the operating system to, to basically tell you when, when something happened. So this is called registry interest. So you can, for example, you can tell the leadership colonel, please inform me when this connection is ready for reading. And then it can just ping back to your Ruby code and let you know. Yeah. So the operating system tells us like this, this thing you're interested in is ready. And that gets pushed onto an event queue. So there's this list of things that are happening. And you can just, and you can just loop through them. So basically, the event loop is doing nothing more than, and just endlessly going over this, this list of events that's in the queue, and, and just doing stuff with every single one of them. Usually it has some kind of storage. So, so, so in the context of a jet client, you want to know the nickname of the person that's, that's, that's, that's, that's connected to a certain stream. Because when a message comes in, you want to be able to like know what this person is. So you can write, write the nickname to back out there. And the event loop can often also add an event. And it can, can ask the kernel to, to, to tell you when something happens. So basically, this is a single process usually in a single thread. And it's just endlessly spinning around and waiting for stuff to happen. And it reacts to something and it writes something to a stream. And then it just goes on to the next take of the loop. So in, so you need quite tight operating system integration to make this work. And Ruby does a gem called event machine that offers this integration. So you, if you would actually do something in production, you would need something like that. At least maybe we'll end up in Ruby itself at some point too. I hear they're thinking about doing like a more, maybe like an active based concurrency model. So then, then stuff like this will be easier. But for now, I kind of cheated. And I made a, I made a kind of like a, a not so nice event loop, but it's at least it's simple. So what we're doing is we're using a fiber and an IO.select. IO.select is a, is a function that's in the Ruby standard library. And you can pass a list of, of stock, of IO descriptors into it, like a socket or something on a file system. And you can ask, ask it, please inform me when one of these, these sockets is ready for reading or writing. We'll get to that in a bit. But first fibers. So fiber is a new, is a new concurrency construct that was introduced in Ruby 1.9, I think. It's kind of like a thread, only much more lightweight. So it has a very small stack of, at the moment, 32 kilobytes per fiber. And it, it operates like, like a thread. But you can pass it and resume it at any time you like. So in this example, we have a little fiber that's, that's looping around. And it, it calls fiber.yield. And fiber.yield is, is, is basically passes until resume is called on the fiber. And whenever resume is called, then the yield call continues. And, and fiber does whatever work. So in this case, the console output would be one, two, three, four. Because we're just asking the fiber to, to put this back to the console. So fiber is kind of like, like a, like a go routine, which only, only go interpreter schedules to go routine itself.  So if you don't resume, then this, this fiber will just endlessly be passed. So again, we have these, the same example, the same TCP server opening, a few chains there. And then we have a list of clients and a list of messages. And we don't need to mute, mutex here, because it's, it's just a single thread. There's, there's no actual concurrency going on. It's, it's just faking it basically. And in the clients hash will store some, some metadata will store a fiber for every connection. So this is basically what our, our, our chat server client representation is. So anytime new connection gets opened, we, we start a fiber that's just endlessly looping and it waits for, for itself to either become readable or writeable. So the event loop will tell the fiber, this, you're not readable and you can do some work and, and then it can actually do the work. I get the sense that this is a little bit confusing. So let me think how to maybe explain it a bit better. I will, we'll just see on the next slide what happens. Hopefully it will be a bit clearer then. So when the fiber is, is in a readable state, it again can read some data from the socket and push this onto the list of messages. And when it's in a writeable state, it again, it, it gets the messages have to be written from the, from the list of messages and writes them back to the client. And then it stores the last write timestamp. So, so it knows that next time around, it doesn't have to send the same messages yet again. And then we get to the actual event loop. So, so this is a fully functioning event loop. It, it just loops endlessly and it starts by trying to see if there are any new connections and, and storing these in the list of clients. Then it tries to ask the operating system, do you have any connections that are, that are ready for reading and writing? And then it reads from the readable connections and it writes from the writeable connections. So we'll, we'll go over all four of these in a bit more detail now. In this case, it's, it's, it's again calling server.except. Only this time we used the non-block version. And the only difference is that server.except just waits for new connections and non-block immediately returns. So it just tries to get a, get a connection. If there's no such thing, it just continues. And we will get a, a, and it will raise an exception. So if there's an exception here, we can just continue with the loop. Yeah, then we get to the next step. We just ask the operating system, please tell us which one of these, these are writeable or readable. Like in a real event loop, this would, this, you would do this in a more scalable way. So this is, this is kind of, this is really a poor man's version of how to do that. And we have sort of the same code again as we've seen earlier. It, it pushes a message back onto, onto the messages list. And a writeable code is also sort of the same. So the, the upside of an event loop system is that it has a very, very low overhead per connection. And the scale's up to a huge number of parallel connections for this, this reason. Downside is that you probably already noticed if you ever used JavaScript, but if you get a more complex event loop system, you often end up with something like callbacks to be able to manage everything. And then the whole thing can get very hard to do because everything is calling each other and that's a huge stack. And the finally, very importantly, since it's a single thread in a single process, like if, if, if you, if it stops, then the whole thing is, is stops. So for example, if we go back to this, this example, if, if the reading in this case would just, would just take a very long time for some reason, like nothing would be read from any client at all. So you do need to have a workload that, that is suitable to, like to be in cut up on very small pieces. So which one to use? Well, as always, the answer is it depends. So if you, if, if, if you have stuff that can crash, then the multiprocessor approach is very good. Multi-training is a nice one because it's relatively simple and you don't need to convert your whole code to using event based model. And the event loop is nice if you need a lot of concurrency.  So, maybe you already checked out the example code. I know Roy has, so at least I can chat with Roy. You can connect to my laptop by, by running a command below. If you checked it out at the absolute beginning of, before the presentation, please pull because I fixed the bug. Did everybody who wants to get that? I should get a different first name. So there's already some people in, in our Slack. So I'm currently running the evented version. So if you look at, if you look at the Ruby processes running in my, in my machine, you can see this had left bottom side of, of the terminal. There's just a client which is running on the right side and the server which is running on the left side. So if we, if we inspect the server a bit more, and this is a list of all the threads that are active in this process.  I did the stock in, in Belarus last week and they, they like hacked this whole thing within, within five minutes. So I am a bit disappointed. Okay, so we, so this is the evented version. And as you can see, there's only, there's only one thread running in this process at the moment. So let's, let's move over to the, to the threaded version. Sorry guys, you'll have to reconnect actually once I restart. So here again, on the left side, there's a list of threads. And you can see that, that is just boots up a thread for, for every incoming connection. I've, I've tried to measure the difference between the performance of the event and the threaded version, but that's, that's kind of negligible. And I think that's probably because I'm using IO dot select instead of an actual proper event system. So we can't really see the difference in any resource usage here, unfortunately. Let me connect in. Okay. So finally, we'll, we'll start the multiprocess version. And this is the one that will break the easiest. That's why I'm doing it at doing it. That's the last one, because if my laptop crashes, I'm like, the presentation is done. So who cares? So this is a different, this is the ps3, tree command, which shows you a tree of all processes and their children. It's, you can see here that that at the top, there's the master process. And then like one step nested into that, we see a bunch of sort of child processes. And well, somebody knows how to write a loop. Yeah, let me just see if how many process we have right now. Oh, so there are about 10 people logged into the server at the moment. Yeah. And this, this, this concludes my presentation. So, so the question is, how did that, how did I apply this month, this knowledge? And so I work a lot on a, on a gem for, for Ruby and Rails, which is called app signal. And it's, it's a monitoring gem. So basically it hooks into into the web server and fetch gets a lot of information and processes that send, sends it back to us. So basically, I've been debugging everybody's weird bugs for, for, for, for more than a year and which forced, forced me to learn this. Well, thank you.


The Hubble Space Telescope captured a display of starlight, glowing gas, and silhouetted dark clouds of interstellar dust in this image of the barred spiral galaxy NGC-1300, a prototypical barred spiral galaxy. Blue and red supergiant stars, star clusters, and star-forming regions are all well resolved in the spiral arms, and the dust lanes trace out fine structures in the disk and the bar.


Arena Sabalenka versus Caroline Garcia is the final for the WTA Finals in Fort Worth for 2022 and both ladies have had different roads to get to the final stage. Sabalenka started the tournament off as the number seven seed and will take on Anstra Burr the number two seed in her first match and after dropping the first set she would come back in an epic three six seven six seven five to get her first win on the board. In her second match she would take on Maria Sacri the number five seed who she had lost to at the WTA Finals in 2021 and unfortunately for Sabalenka she would lose again going out in straight sets two six four six. In her final match she would play against Jessica Bogula the number three seed in a must-win match and the pressure was on for Sabalenka but she came through getting through in straight sets six three seven five to advance to the semi-finals. In the semi-finals Sabalenka would have to take on the number one seed Igasriontec and after a good start she would drop the second set but then dominate in the third getting through in three six two two six six one to advance to the final. Garcia started the event off as the number six seed. In her first match she would take on the number four seed Koko Goff and after a close first set she'd eventually get through in straights six four six three. In her second match she'd take on the world number one Igasriontec a lady that she had beaten a couple of months earlier on the clay in Poland but unfortunately for Garcia she couldn't do it again which fiancee getting through three six two six. In her final match she would take on the number eight seed Kazakina and this was a do or die match because both players were playing for a semi-finals spot with the winner going through and the loser going home and after dropping the first set Garcia would come back in an epic prevailing in three four six six one seven six to advance to the semi-finals. Garcia would take on the number five seed Zachary in the semi-finals a player she had a battle with in Cincinnati a few months ago but this match would be very one sided as Garcia would win in straight six three six two to advance to the final. These two ladies have played four times before with the head dead split straight down the middle at two apiece but Garcia did win their last match in Cincinnati that was a couple of months ago and it wasn't even close in the final set six one but it did go the distance and it was three sets. If Sabalenka is going to win the serve has to work we know that's the problem with her every match. If the serve doesn't work then usually her game doesn't work but this is most important that's the thing that worked against Friantec she served well when she needed to and she needs to be aggressive as well like she was against Friantec. If Garcia is going to win she needs to bring the variety back she played very solid against Zachary who wasn't quite on her game but coming to the net and being the aggressive player moving Sabalenka around that's what's going to get the job done because Sabalenka on the run is not as good as when she's standing on the baseline. This is going to be a very fun final I don't think anyone expected to have these two in the final against each other especially after the group stage when Zachary and Friantec both dominated and both getting upset it's going to be a very fun final I don't know who to pick I guess I'm going to go with Sabalenka because she looks so good against Friantec let's make it a three setter of the final match of the year but let me know down in the comments below who do you think is going to win this final


Requirements for English teachers around the world, Europe. What do you need to be able to work as an English teacher in European countries? France. Qualifications. Teflor TESOL certificate, minimum of 120 hours required. Native, non-native speakers. Native speakers or fluent non-native speakers. Experience. Some teaching experience preferred. Visa. EU citizens preferred. Other nationalities will require long-term visas. Germany. Qualifications. Teflor TESOL certificate, minimum of 120 hours required. Bachelor's degree preferred, but not always required. Native, non-native speakers. Native speakers. Experience. Some teaching experience preferred. Visa. Long-term visa applied for after arrival. Other, easiest country in European Union for non-EU citizens to get work permits. Italy. Qualifications. Teflor TESOL certificate, minimum of 120 hours required. Native, non-native speakers. Native speakers. Experience. No experience necessary. Visa. EU citizens preferred. Other nationalities will require long-term visas. Czech Republic. Qualifications. Teflor TESOL certificate, minimum of 120 hours required. Native, non-native speakers. Native speakers or fluent non-native speakers. Experience. No experience necessary. Visa. EU citizens preferred. Other nationalities will require long-term visas. Poland. Qualifications. Teflor TESOL certificate, minimum of 120 hours required. Native, non-native speakers. Native speakers or fluent non-native speakers. Experience. No experience necessary. Visa. EU citizens preferred. Other nationalities will require long-term visas. Spain. Qualifications. Teflor TESOL certificate, minimum of 120 hours required. Bachelor's degree preferred, but not required. Experience. No experience necessary. Visa. EU citizens preferred. Other nationalities will require long-term visas. Russia. Qualifications. Teflor TESOL certificate and Bachelor's degree preferred, but not required. Native, non-native speakers. Native speakers or fluent non-native speakers. Experience. No experience necessary. Visa. Work visa required. Austria. Qualifications. Teflor TESOL certificate, minimum of 120 hours required. Native, non-native speakers. Native speakers. Experience. No experience necessary. Visa. EU citizens preferred. Other nationalities will require long-term visas. Switzerland. Qualifications. Teflor TESOL certificate, minimum of 120 hours required. Native, non-native speakers. Native speakers or fluent non-native speakers. Experience. No experience necessary. Visa. Work permit required. Georgia. Qualifications. Teflor TESOL certificate, minimum of 120 hours required. Native, non-native speakers. Native speakers or fluent non-native speakers. Experience. No experience necessary. Visa. Visa free entry for many countries. Ukraine. Qualifications. Teflor TESOL certificate, minimum of 120 hours required. Native, non-native speakers. Native speakers or fluent non-native speakers. Experience. No experience necessary. Visa. Work visa required. Portugal. Qualifications. Teflor TESOL certificate, minimum of 120 hours. Bachelor's degree preferred, but not required. Native, non-native speakers. Native speakers or fluent non-native speakers. Experience. No experience necessary. Visa. EU citizens preferred. Other nationalities will require long-term visas. Turkey. Qualifications. Teflor TESOL certificate, minimum of 120 hours required. Native, non-native speakers. Native speakers or fluent non-native speakers. Experience. No experience necessary. Visa. Work visa applied for before or after arrival. Work visa applied for before or after arrival.


Okay, I'm not really going to talk a lot about the mechanics of whole genome sequencing. I'm going to describe how the Partner Center for Personalized Genetic Medicine is organized, describe the laboratory for molecular medicine, which is our CLIA-certified lab, talk a little bit about our plans to launch this service, which is very much along the lines of what Howard and David are doing at MCW, and focus in on gene insight lab and clinic as a critical piece of software and something that may be shareable with other members of the group. So how is PCPGM organized? We have a set of research cores, which are sort of the standard cores that are also used by our CLIA-certified lab, and these research cores both support research and support the clinical lab, and they are CLIA-certified. We're supporting about $140 million of research across Partners Health Care. Just for those of you that don't know, Partners Health Care is the umbrella organization for Massachusetts General Hospital and Brigham and Women's Hospital, and involves a number of ancillary facilities that are linked to those two academic medical centers. So this is all CLIA. We also have a very active RPDR and electronic medical record that's used for research. Sean Murphy actually runs this. It's not actually technically part of the center. Most of the research that's being done here is not genetic. There are about 3,000 projects that are going on, and over 4 million Partners patients that are being used for research using the electronic medical record. And this is the piece that's not yet built. We've just actually gotten approval to go forward with the Partners Biorepository for Medical Discovery, which is going to be a biorepository which will be linked to both the CLIA lab and to the electronic medical record. And our goal is to have the biorepository actually CLIA-certified as well, because going forward, we're doing this in a consented fashion, and I think the reasons for that are manyfold, but I think the most important is, is that we want to be able to do research on these patients, but also be able to push things forward in terms of clinical research and clinical care, and it's going to be a lot easier to do that if this is both CLIA-approved and if the patients are consented. So that's how the center is organized. So between the investigators that we're supporting here, currently there is a service crimson, which is now, I just became operative at Mass General, has been operative at the Brigham for the last three years, and that's supporting about $40 million in research. So between $140 or so million dollars worth of research that's using the EMR, another $150 that's using these cores, and the 40 here, we're supporting about $300 million of research for approximately 400, 500 partners investigators across the health care system. And I think, sorry, perhaps the most important part is the IT infrastructure that supports all of this, because without this IT infrastructure, we wouldn't be able to have samples flowing seamlessly from the CLIA lab to the research cores, to the biorepository, to other investigators, samples going to the Broad or wherever. So the IT infrastructure here is clearly the major investment in terms of the center and the way it works. So a little bit about the laboratory for molecular medicine. Heidi Rehm, who was at the previous NHGRI workshop with Robert Green last week, is the director of the lab. This lab's been in existence since 2003, and we do about 4,000 genetic tests a year. We do these tests for both the two partners, hospitals, but also for medical institutions around the country and in some cases around the world. The bulk of our testing is in cancer and cardiovascular disease. We do have some other oligogenic and monogenic traits that we test for, and currently we have tests for over 200 genes. The challenge here obviously, and this is an example of one of our first tests, both are two academic cancer centers, produced papers within a few months of each other looking at EGFR as a gene for a treatment response for small cell lung cancer, and within three months the lab had a test up and running to test patients, and we still do the bulk of the testing for Dana-Farber, although the MGH does their own testing now for EGFR. A little bit of context in terms of the evolution of clinical genetic testing, which I think gives maybe further justification, if you will, for the approach that Howard outlined earlier. You can see along here how the evolution of testing in the lab has occurred, and we've expanded tests and expanded the number of tests in the areas that we've been doing genotyping, but we're reaching the point now where it's going to cost as much to genotype the whole genome as it will, in fact, the cost of the genotyping will be less than the cost of our cardiarchip genotyping. The cardiarchip test, I think, costs on the order of $3,000. It's likely that the whole genome, at least the genomic sequencing portion of that test is going to be well below that in a year or so. So we're entering this logarithmic phase where whole genome sequencing is going to be relatively cheap, but the thing that's going to lag behind, as has been pointed out by a number of people already, is the analysis and the ability to build content to deliver to practitioners. That's going to be the major challenge going forward. It's not going to be the sequencing itself, and we anticipate that all of our tests now are targeted next generation sequencing tests, and we expect to be completely out of that business in two years, simply because it's just not going to be economically viable to do it. So our service is organized very similar to the way MCW has organized theirs. We're outsourcing the actual sequencing to Illumina and complete genomics. We're going to concentrate all of our efforts on data analysis using the existing infrastructure, the LMM, and all of the things that Howard talked about in terms of patient workup consent, oversight, clinical committees is all going to be in place, and we're probably going to launch this so we would like to launch it in July of 2012. The major factor in terms of whether we will be able to do that or not is going to depend on our IT infrastructure, I think. I think it's interesting to look at this from the context of the clinician's perspective. The amount of information that's going to be generated for clinicians is truly daunting, and new information can emerge on any of these variants at any time, and new forms of support are already needed to stay up to date on the limited number of variants that were identified using the clinical support tools that we have now, and the infrastructure, depending clinical process, need to be established to allow clinicians to retrieve and manage genetic results, to link clinician to experts capable of determining the implications of each of these genomic variants and keep them up to date. Obviously, this whole process, we've linked to the clinical genetics programs at the two hospitals, Mike Murray, who runs clinical genetics at the Brigham, and David Sweitzer, who's his comparable person at Mass General, are involved with Heidi and Robert Green, and me as we formulate the plans to launch this service. This also creates significant opportunities for partners' health care in particular because of tools that we've already developed and would like to share with people here. You've got this constant flow of cases that are going to the geneticists in the lab to sign up these cases. You've got this evolving knowledge base and the need to continuously update the electronic medical record and report information to clinicians. We've developed a tool that we call Gene Insight that we use both as a report-generating engine, but is used in the laboratory as a knowledge base. We keep information on all of the variants that we've genotyped in the lab, and we obviously use this to report the results to the electronic medical record. And both of these, I think, are going to turn out to be very important. Heidi Rehm has actually put in a U41 grant to address the issue that people have been talking about here, which is a huge issue, which is variants linked to clinical phenotype allele frequencies, allele frequencies in people that don't have the phenotype, standard ways of reporting and annotating variants. This is going to be a huge issue going forward. And if this group decides to make that an issue that people want to collaborate on, I think that we have several people in our center who would be very interested in participating in that. So this is what Gene Insight looks like if you're at a terminal in your office. This is a patient named Curious George who happens to have a cardiomyopathy, and he had a variant that was previously classified as of unknown significance that has been now reclassified as pathogenic. So we can update these in real time. We can push this information to the clinicians. We can provide decision support tools through this software and help to enable the clinicians to manage these patients and to help them seek support from genetics experts if they need that backup and support. So, and I think that this software, although it is clearly at the terminal end of the pipeline that Howard described, it's still software that is potentially valuable, and we'd be interested in sharing it with others and working with others who might want to use it. No, no, it's not sitting on a research database. And this is just the people who have helped get this center off the ground. Yes, Debbie. So, should I wait, or can everybody hear me? Great. Scott. Yes. Tell me what made you change from one category of pathogenic. That's a big change. For an individual variant? Yeah. So what was the level of evidence that made you make that switch? Yeah, I'm probably not the best, you know, I don't run the clinical lab. That's sort of like the question that Howard deferred to David. I think that the geneticists in the lab have a whole bunch of criteria that they use to decide whether something variant changes. They look at the literature, they're looking at a lot of different things. And I agree with you that that whole issue is one that is, well, I think it's not just a nightmare, it's one where there's not clear standards, and some people might do it one way or another, people might do it another too. I mean, people are beginning to look at this because it's such an important question, but I do think it is key because what has been reported in the literature, if you go today with modern databases, what in a family segregated and what was without functional studies or even some maybe not appropriate functional study caused or said was causal, you cannot hold up. Yeah, well I think that, you know, there's clearly variants that were found for monogenic disorders where the variants are in linkage to this equilibrium with the causal variant and it was reported that that was the causal variant. So I couldn't agree with you more that this is a huge area. I think it's an area that's going to demand a lot of attention. What I wanted to focus on here was not so much the process that we do that, but the fact that the software allows us to change the interpretation. I think that's going to be important because I think that going forward, this is not something where it's going to be set in stone. Yeah, but I think it's important also if you're taking data from a provider, what they're providing, let's say, an aqueous setting is not necessarily the end of, you know, no question. And a clear certification doesn't mean that an interpretation is set in stone. So you're looking at a lot of places to reduce costs and you're doing some of the whole genome sequencing then at the clear labs like Illumina. And when you look at these like 4,000 bucks and they'll do the alignment, call the variants with something that's good enough, do you see bringing that, I mean, I guess I'm wondering why bring that back if you have to re-invent all the analysis questions and all the initial labs set up? Is that a part that you really see needs to be in-house? I think that, you know, we have currently two high-seeks that are being used for research sequencing. We're not doing any of the whole, we haven't started doing whole genome sequencing ourselves in the research core. I think that whether we ultimately bring this in-house or how much we do at partners and how much we rely on Illumina and complete genomics is a fluid thing. It's not something that's been set in stone. I don't know that we'll, the one thing I'm pretty sure we're not going to do is we're not going to build the giant sequencing facility in Waltham to sequence all partners' patients. I don't think that's probably in the cards, but how much we actually do ourselves and how much we outsource I think is an open question. I think for us, the issue of the analysis and the interpretation is what's paramount. But when you say analysis and interpretation, I think that was different than what was referred to earlier, which is how do you call the variance? You're real concerned with analysis and as interpretation. So there are kind of two- No, I think we would include that as well. And I think that all of the issues that were described are issues that we are going to consider in terms of how we do this. Nothing here is set in stone. Virtually everything about this is a moving target. So how we decide to do this today may be very different from how we decide to do it, you know, six months or a year from now. Scott, you may have mentioned it, but can you clarify whether the gene insight is designed as a standalone tool or is it in any way linkable with an EMR to talk to EMR? It's absolutely linkable with an EMR. You know, several other health systems actually have been using it. We collaborate with Intermountain Health. They're using it. So it's definitely linkable with other software and other EMRs. Sir, I had the exact same question, but that means it's a standalone tool, because if different EMRs can talk to it, it means it's not tied to a specific EMR. Is that correct? That's correct. And then there's the laboratory, you know, that basically this resides between the clinical laboratories and the information systems, and so you really build one interface from a clinical site to a gene insight, and then you can interact with all the laboratories that use that. And so it just simplifies the interface construction with otherwise in a distributed single gene, gene by gene type of thing, you have an infinite number of interfaces that you have to build. Now, again, it may become a moot point if we all move into next-gen whole genomes, but at least at this point it was a very pragmatic solution. It's a follow-up on your question. As all of these modular components are proposed and developed by different people, is there any idea that in the end something like data.gov and semantic technologies will be somehow the milieu or the middle layer that all these things used to talk to each other? Anyone has a comment on that? So this is something that groups are talking about, and specifically since this involves a lot of moving and pushing of data around, the clinical genomics group of HL7 has specifically constituted a working group within their working group to look at whole genome and whole exome sequencing and how that data can be characterized, and they have other working groups that have looked at other types of data models within this arena for family history, and there are additional working groups that are outside of the genomic working group that do clinical decision support models, but essentially all building on a common standard language so that there's relatively seamless movement of the information that you want, as long as the information system is built using that type of a communication standard, in this case an HL7 version 2.x.


Hello and welcome to Cracking Cicada 3301, the future of collaborative puzzle solving. I'm Puck and today we're going to be giving you a brief introduction to the Cicada 3301 puzzles and then we're going to be talking about how our community, Cicada Solvers, about 7,000 people on Discord is working together to solve this. So to get the obvious question out of the way, what is Cicada 3301 and who are we? Cicada 3301 is a pretty like mysterious group. There's a lot of talks about that. So there are basically a mysterious international organization as they have called themselves that has released a, that has released three increasingly difficult cryptographic puzzles. The first one was in 2012 which went solved, 2013 solved and 2014 which the current step of a 58 page book of runes called Liber Primus which has gone unsolved. Only two pages of which have been solved which is right away and the 56 other ones have stumped solvers for nine years now. And for who those solvers are, we tend to flock to like this main hub called Cicada Solvers. It's a Discord server and it expands elsewhere into like reddits and stuff like that. But the main hub is the Cicada solvers Discord server. It's got about 7,000 people and it's the main group of people interested in the Cicada 3301 puzzles. All of us are from this group. I am Puck. I kind of take the role of the community organizer. I've been here since about 2019 and like been organizing these things called voice sessions which we'll touch on later since 2020. And I'll hand it over to Taiwo here. Hi, I'm Taiwo. I take more of a technical role in the community. I do things like tool creation of tools but also kind of server administration technical things like that. And also kind of like a higher level role of sort of community direction. Things along those lines. I have been in the community since 2013. So since kind of before the most recent stage but not really since the beginning but still for a considerable length of time. And it definitely feels like it. I found great inspiration from these puzzles. I've grown significantly constantly humbled by them even after solutions were coming out. And that's kind of my main motivation to sort of introduce the puzzles to new people and to have others grow and just grow as I have grown. That's kind of my primary inspiration. Also if we manage to solve the unsolved step, that'd be just a sweet bonus. I'm handing it over to Clockwork. Hello, I am the Clockwork Bird. My job is community engagement. Part of what I do is I am almost like a tour guide of the interactive museum that is solvers. What I like to do is I like to host those voice sessions. I also, in addition to hosting things like technical solving sessions, I like to talk about the art, literature, and the philosophy that have been utilized throughout the puzzle. My background is in anthropology. Specifically I have an interest in ethnographic work. So Cicada has been an opportunity to see a digital community and see ways that we can build engagement and bring together people with different technical skill sets and different skill levels and all have to collaborate in the same place on the same thing and have the same level of fun. I'm going to pass it off to my buddy, Ari. What's up, nerds? I hope everybody is enjoying and is very excited for DEF CON 31. I know that we all are. My name is Artorius. Thank you, thank you. My name is Artorius. I consider myself something of an archivist of the Cicada 3301 phenomenon. I created a website called cicadasolvers.com, which is essentially intended to be an improvement upon the uncovering Cicada wikia. Additionally, along with my co-speakers here, we run a podcast called Cicada Cast. This is intended to be an educational exploration of all things Cicada 3301. I also moderate the R Cicada subreddit, which has 30,000 members. In addition to the Cicada Solvers Discord, which has about 7,000 members. That's about it for my introduction. So now back to Puck. All right. So what a lot of people have heard about Cicada 3301 is just a matter of misconception. So we figured might as well just clear all that out of the way in case any of you guys have heard anything. So on social media, especially YouTube, you see a lot of fake puzzles, which might sound quite strange because 3301, the group behind these, has literally given PGP like you can verify that something is from them and people still make fake puzzles and like try to, I don't really know why people just like try to like game jack Cicada 3301 and like they do cryptocurrency scams. So if you see that, do not fall for it. They are not Cicada. And also the news where you guys see that especially back in like 2012 when the puzzles were really popping off. There's a lot of click bait like yellow journalism. They really focus on like Cicada 3301 is a mystery. Like the Wikipedia page will call it like it seems like a cult and stuff like that. And in reality, they're just a group that I'll hand over to Tywo here to actually show who they are in a little bit. Sorry. My bad. And also there is a kind of like the perfect example of this is this movie Dark Web Cicada 3301, which is not affiliated with Cicada 3301. They just, this image in the bottom right, I don't know who those people are but somehow that's who they think Cicada is. And in reality they're just... Those babies are not PGP verified. Yeah. Like I don't know. I'll hand it over to Tywo to explain who they actually are. Thanks, Puck. That was plenty about who Cicada aren't, isn't. But I want to talk a little bit about who they are or at least... Oh, thanks. At least what we know about them. So basically they're not supernatural. They're not some kind of religious cult or anything out of this world. But they're somewhere... One thing is true. They clearly have a ability to produce consistently high quality, high complexity puzzles with clear themes and very successful motives to bring people into privacy and cryptography and also areas such as literature and esoterica as well. So to put it into kind of rules of thumb it's somewhere above like a bunch of neckbeards, somewhere below a new world order, someone with enough money to purchase infrastructure and disseminate materials across the globe but someone probably or a group less capable or willing to put probably months into planning something with no clear financial incentive or corporate affiliation. They are clearly well-intentioned. They're incredibly skilled. They have basically very good privacy practice. Their ability to remain anonymous is second to none. And they do so whilst also informing the solvers of the puzzle how to follow in their footsteps and communicate anonymously, retain privacy online and the significance and importance of doing those things. The puzzles contain many references to esoterica and it becomes a strong theme throughout the puzzles as a whole but although esoterica does play this core role to who they kind of personify themselves as of current although the usage of the esoteric themes have been used in the solutions of the puzzles to an extent. They've never been used in a way that is exclusively, that couldn't have otherwise come about through intense kind of factual analysis, things like frequency analysis and things like that. Yeah, so that's a little bit about what we really know. I kind of skipped a point about they're not criminal organization and they've come out multiple times to say that they're not interested in criminal activity but also to denounce others who claim to be them committing crimes. It's happened in the past. How do we know this? I defer to my good pal, Clockwork, he's going to tell you a little bit more. You know, we don't have to guess about who, you know, who Siketa is, what they're about and why they're doing it.  In 2012, the round finalists were invited to participate in collaboration with Siketa and they received PGP verified emails that discussed the who, the what, the why. If you guys would like, that QR code leads to our nice little leaked email on our wiki. Now here's the key points. We are an international group. We are drawn together by common beliefs that censorship is wrong, that tyranny and oppression of any kind must end and that privacy is an inalienable right. We are much like a think tank in the ideas that we advocate are liberty, privacy and security. Excuse me. We are much like a think tank in the idea, in the ways that they research and develop tools that forward liberty, privacy and security. What's interesting to know about the, about the state of goals of enhancing liberty, privacy, security is that this seems to be inspired with or align with cipherpunk philosophies. And it's important to know. We are not saying who they are. This is not a who. We're saying this seems to be what they might have been inspired by. If we look at the, if we look at the cipherpunk manifesto, you know, privacy is a necessary, it's necessary for an open society in the electronic age. Frame of speech even more than privacy is fundamental to an open society. Cipherpunks deplore regulations on cryptography for encryption is fundamentally a private act. That in this context it would appear as though cicada is indeed inspired by and gels with this idea of empowering people to secure their privacy. There's a part at the end of the cipherpunk manifesto that says for privacy to be widespread, it must be part of a social contract. People must come together and deploy these systems for the common good. Privacy only extends so far as the operation of one's fellows in society. And cicada is raising awareness of the deploying of privacy to the person to your left and right. It makes people more aware of what, what is the, what are the threats to their privacy and what are the tools they can use to secure it. I'm going to pass this off to my good buddy Artorias to give us a little bit more context for what happened after the 2012 leaked e-mail. Thank you clock word. So in this speech so far we've talked a little bit about who cicada 3301 is or more accurately who they are not. But let's get down to the, to the meat and potatoes of the whole Internet's hard mystery thing. What has cicada 3301 done to justify that moniker? Well, let's start in, let's start in 2012. In 2012 the unassuming Caesar shifted final dot JPG image which was found on 4-chance paranormal board X set off a cacophony.  In 2012 cicada 3301 upped the anti a little bit. They departed from the world of the purely digital and ventured into real life rather than just making a step that was only confined to the Internet in 2012 across four continents, more than a dozen major cities across the world. Posters, posters containing cicada 3301's logo and a QR code that could be scanned to lead to the next step were found flabbergasting the solving community worldwide. Somehow in 2013 they won up themselves again. They started introducing thematic elements and philosophical stylings into these cryptographic challenges. They really defined for themselves how the world would view them in 2013. They created their own operating system. They wrote, produced and released various pieces of encrypted music. And to top it off, in 2013 they gave us the gametria primus. If anybody here does not know what a gametria is, it's essentially just an easy way to correlate numerical values to a given character set or in our case a set of 29 food dark runes. This gametria primus was then used in 2014 when the release, the slow release throughout the 2014 year of 17 pages of what could only be described as a digital illuminated manuscript complete with rubrication, delimiters, marginalia, anything that you could want from an illuminated manuscript. We also had to brute force an RSA key multiple times. But even this, despite those monumental achievements, despite those monumental achievements, that was not even the culmination of the difficulty of Cicada 3301's challenges. To tell you a little bit more about what's considered possibly 3301's masterpiece, a deviously fiendishly difficult thing, I'll let Taiwo come speak about it. Thanks all. So, yeah, after these three years of incredibly well crafted puzzle steps, we find ourselves at the most recent, as we mentioned earlier, unsolved stage of the puzzle. You can see that the previous stages were nothing to kind of joke about, but I want to talk a little bit about the level of complexity we're talking about with why it's been, what, nine years now since the release of the pages and we still haven't made, well, very much progress. I'll go over that. So basically, at the end of the 2014 puzzles, a, oh, at the end of 2014, a set of 58 runic pages were released. The complexity of which were very clearly and obviously to solvers at the time significantly greater than what had came up until that point. The puzzle was attacked from every angle, obviously the attempt at decrypting the contents of the runes, but also investigating the contents of the image files themselves and trying to analyze the images contained within the margin area of the pages. You can see some examples here. The last of these 58 pages, up until now, only two of which have been solved, they were almost, they were almost immediately solved after the release of the pages. The ultimate page was solved almost disappointingly with a direct translation into English, but again disappointingly gave no clear instruction as to how to continue. The penultimate page, infamously page 56, the deep web hash page, was solved in a somewhat more complex way. A totent stream of, a totent stream cipher, a running key of consecutive prime numbers using Fs as, using F runes as interrupters. The contents of the page instructs us to search the deep web for a hash, a 512 bit hash, and something that we originally presumed char 512 as many of you may be thinking, but have gone on to establish multiple potential algorithms that could have been used as the definition of the hash remains undefined by the pages themselves. In 2017, the search naturally scoured the dark web as well. The tour network was something they used frequently in the past. In 2017, the search discovered a vulnerability in the tour network, something that basically undermined the anonymity and privacy of the entire protocol to disclose unlisted hidden services the moment that they're broadcasted to the network without being indexed. This search piqued the interest of basically security researchers at the Northeastern University who had an open investigation running multiple honey pot onion services, dubbed onions. I thought that was funny. And they identified the search as a large scale attack on the tour network. However, despite being able to identify and hash approximately 90% of the hidden services available at that time indexed or not, nothing of value or nothing was found that hashed to the aforementioned hash. Since then, broader strokes have been applied going into the more generous definition of deep web searching pages on the clear net that haven't been indexed by search engines. Tools were created to search multiple hashes using tools that were created by the community, a browser extension named 3301 hash alarm. You may download that yourselves. To help the effort with no input from yourself, it automatically hashes every page you visit and privately informs you whether or not you found the deep web hash and instructs you on how to notify us of that. I'll hand it over to Artorius to talk a little bit more about the community that we constructed to create such tools that help the search for the deep web hash. Thank you. Thank you, Ty. We are currently going through these slides a small amount too slowly so this one's going to be a little quicker. It's just an introduction to our community. Basically, the cicada solvers community is the largest, most organized, most well-known group of individuals still actively trying to make progress in 3301's current step, Libre Primus. Despite tens of thousands of failed solving attempts by the same number of previously enthusiastic solvers, very little progress has been made. A decade of stagnation can be difficult, yet we are still actively pursuing what can be considered an impossible task or at least extremely difficult. To talk a little bit more about how the cicada solvers community came into being and a little bit about the evolution throughout the years of this community, I'll hand it right back to Ty. Hello again. So just let me tell you, apparently really quickly, about how this community came to be. So as mentioned earlier, the puzzle began on 4chan, already a discussion forum, but not exactly the best place for constructive progress to be made. So we quickly garnered the attention, the complexity and intricacy of the puzzles garnered the attention of the active ARG solving community inhabiting the 3 node IRC. Soon thereafter, an IRC channel was created of our own dubbed cicada solvers. This naturally became the central hub of solving attempts, gaining the reputation for a public approach to solving where all information was shared. And if you weren't sharing information, well then what are you doing here? However, as the IRC channel was started in 2012, the release of the LP in 2014 is mentioned previously, gave solvers such a humbling that the fairly active for 3 node IRC 400 members around its peak was decimated over the years to around 5 to 10 active users. At the time, the operators and moderators of the cicada solvers IRC came together to stop the community from dying out. There were many things considered, but at the time Discord was becoming very popular and also very controversial in the privacy and security community. The irony of Discord being a proprietary platform that makes money predominantly by selling all of your information is not lost on us. However, the free and scalable nature of the platform, the set of convenient tools that it provides and also the, I can't remember the last one, Discord was what we ended up going with, but with years of experience managing the community, we knew what would stick and what wouldn't, how people could succeed and what led people to fail. So we set to construct a set of guidelines that we should follow to create a community that is constructed specifically towards the successful accomplishment of an almost impossible task with very little definition of progress over the years. To describe a little bit more about what sets us apart, I'm going to hand you over to probably Clockwork. There it is. Probably me indeed. So what makes us different from, you know, what makes us stand out from the total solving community is that we are dedicated to sharing everything. That, you know, whatever, whatever someone does, you know, it's all about a community of sharing of collaborating. Gatekeeping is the death of collaboration. So ensuring that we can create a community where people feel open and engaged and really have fun with it is one of our goals. And as was mentioned earlier, what differentiates us from fake puzzle communities is that no PGP, no cicada. It's that simple.  No. I mean, you saw that book of 58, you know, cryptid pages. We have enough to worry about. I don't have anything to go about following some weird goose chase versus a decoy duck chase. So what's also important is that we have clear guidelines, clear rules, clear rules of conduct, not only for our users before our staff members. You know, ways that we want people to engage with users in order to educate them, to help them grow. Productive ways of giving feedback, that's the style of workshopping versus critique and saying someone is wrong. Something else is that, as I said, we guide.  Something else is that we try to document what worked and what didn't work. And that's important. We, you know, you look in other communities and we don't, we don't see that same level of documentation.  And it's important because, you know, even if you're not going to be active, you don't have to be active in the community. But if you just want to know, if you just want that material, you can find it. So I am going to pass it off to our main art, to discuss our main challenges. To our art, yes, there you go. So some of our main challenges as a community. You can see up here, documentation, fake puzzles, and the revolving door culture of new solvers coming in, getting exhausted with failed attempts, leaving, rejoining, wondering if there's been any progress, there hasn't, so they leave again. I want to talk a little bit about why documentation is so hard. First of all, documenting a failed attempt at anything is not something that many people are, are very willing or enthusiastic to do. Not only failed attempts, but even successful attempts, if you do not document them properly, if they're not reproducible, if the methods used are not very well explained, then it's going to snowball into people thinking, okay, well, you say that this worked. Can you prove it? Can you show us? As far as documentation platforms go, we've tried pretty much everything. If any of you have been to the Uncovering Cicada Wikia slash fandom, you'll know that it's a bit of a mess. It's a little bit of a mess. I can say from personal experience, experience trying to create the website cicadasolvers.com, which is like, not necessarily a replacement, but it was meant to be an improvement upon the Uncovering Cicada Wikia. It's very hard, and we've tried pretty much every platform that you could think of. We've had GitHub's, GitLabs, Weekends, Trello's, forum, address everything. Nothing sticks. I mentioned the revolving door lifecycle of a solver, so if you can imagine, if you can imagine, somebody who has just heard about Cicada 3301, they might not necessarily be the most technologically inclined. They might not even know anything about cryptography, but they hear about it. They think it's interesting. They join the community. They try what they can, and inevitably they get humbled. We've all been there. None of us are as smart as we want to think we are.  You leave, and then eventually you get bored of normal life. You hop back into the server. You say, hey guys, I haven't been around here in a while. Has there been any progress? No? I'll see you in another few years. That's the life cycle of a solver. So to make a small departure from our challenges, I'm going to let Puck here discuss some of our advantages as a community. So we've kind of, over the years, we've learned a lot, and we've kind of been able to capitalize on that. First thing, something we didn't really have to do, too much work about. We kind of just have a lot of people through different documentaries over the years. They kind of just filter in as it gets popular. So with literally over 7,000 people, a lot of people means there's going to be a lot of attempts.  And as a result of that, we obviously have a lot of solving attempts, and we have to kind of organize that, which is this main thing, organization of manpower. We do these things called voice sessions, which I'll touch on in a bit. And also, something Tyra will touch on in a bit, is active tool development. We have a very big open source, like kind of an open source culture. Like if you're going to solve it, you're going to need other people as well. So we definitely promote that. So for our community size, generally, more people, the better. It's going to be a positive feedback loop, because more solvers, you're going to have more ideas. And as a result of that, you're going to say I'm a solver. There's a higher chance that there's an idea that I like, and I want to solve it. That's very important because as we are all hobbyists, it's not really like we have any incentive just to go out and try something. There needs to be that what's in it for us, and that's the enjoyment factor. And so the more ideas there are, the more likely you are to find something that you like, and you're going to have more motivation. And generally, that could turn somebody who's a non-solver into a solver, and then it'll just kind of keep going as a result of that. And now this is kind of the main thing we've developed over the past couple of years. In like December 2019, there was like a message in the Discord server kind of just saying like, can we all basically just get into like a voice channel and just talk about like where we should do or where we should go next, like what solving attempts we should run and how can we work on them together. And I kind of took it upon myself. I had free time.  I didn't really have anything too important going on. And I was like, sure, I'll just like kind of organize it. We'll do some like weekly events. We'll do some monthly events. We'll all get together. We'll schedule it. Everybody can just like set the date in your calendar. Come by if you want. Don't have to say anything. But generally, we had over like 25 people show up at the time, which is pretty crazy because there were like three people talking at a time and it was kind of, it was a pretty big lull in the community at the time. And we kind of just turned these things over time. We now have more hosts because we have this culture again, like this open source culture. Anybody can be a part of it. The more people, the better. So we've emphasized that anybody can do a voice session. Some random person here, if you want to join do a voice session, I'd recommend like reading the Wiki first, but sure, go ahead. But... I still haven't read it. That's a big running joke of us, read the Wiki. And this big teaming up on solving is the big emphasis of it. And for tools, I'll hand it over to Tywo. Hello again. Really quickly, this next slide, previous slide. Quick spoiler there. Really quickly, I wanted to touch on the community's kind of general effort towards focusing on the organization of a community set of tools and resources. As we kind of touched on the cycle of solvers, a common sort of landing place for people who have been in the community for a long time, such as myself, is to focus on the tools that help others to succeed. Sometimes even the combination of resources to help other people to advance their theories or to try out their theories as quickly and as easily as possible, kind of standing on the shoulders of giants kind of thing. Much like you may have heard of a recent breakthrough in the Zodiac 340 cipher solved after 54 years, basically through the creation, the community creation of custom tools used specifically for a custom alphabet. And we take great inspiration from this. One of the main challenges, however, similar to the Zodiac ciphers is the utilization of a separate alphabet as described in the gematria primus. It's 29 runes, but it's more complicated than meets the eye and the vast majority of cryptographic tools just aren't compatible with the types of translations that we have in the Libra primus. Basically we have kind of three main areas of attack. We've got the deep analysis tools, almost infinite levels of configuration. You could probably spend years learning all of the different ways to manipulate these tools in order to implement your ideas and kind of follow through how the process naturally progresses and to come up with basically to inspire yourself to continue with even more further ideas. The second area is more of like a middling area. If you have a quick idea, we work on tools that allow you to rapidly throw things together. Things like discord bots that just let you quickly test out a theory, Python libraries that allow you to just remove all of the context of the different ciphers and ways of using them and just saying, I wonder if it's a vision air shift with this key, but on the runes, but also skipping, interrupting the F characters as frequent in the puzzles. Generally, and then the final area of focus is on the sort of external non-technical area. Tools that are widely adoptable. Things that require basically no input and that we can disseminate amongst large groups of people such as the browser extension that was mentioned previously. It's generally our goal as a community to unify our resources and that's how we plan on kind of moving forward with this. Speaking of moving forward with it, I'm passing it over to Artorius, my guy. Come up here. Speaking of moving forward with it, the theme of this DEF CON is the future will prevail. We believe that the Gate of Solvers community embodies this spirit and the lessons we've learned pursuing a nigh impossible goal can be something extremely valuable to anyone who wants to see a future of digital liberty, privacy, and security rights. I want to add, in our experience over the years we've seen many people be influenced and go into the future and be influenced by this puzzle and it affects their lives. Solving is a learning process. They're learning how to solve people are introduced to the fields of cybersecurity, infosec, cryptography, and computer science. Fields that are actively shaping our future. In trying to solve a bug book, people end up in fields that are solving the problems of the future. As something of a closing comment on this idea, I would like to say that the future will prevail because we are all building it right now. It's not a matter of predicting what may or may not come. It's about taking active steps to ensure a future that is good to live in, not only for yourself, but for the people around you and the people you care about. Look to your left and to your right. That person's understanding and concept of security and privacy is just as important to your safety as your own. One last thing I would like to say is that if you want more detail about how the actual stages throughout 2012, 2013, and 2014 were solved, we will be speaking at Crypto and Privacy Village at the Flamingo 4pm tomorrow. We're going to get very deep into the history of the actual way that these challenges were solved. Thank you.