So, hey everyone, I'm Talia McCormick, and today I'm here to talk to you on Mono repo madness dependencies, license compliance, and automation. In my day job, I work at Fossa, where I'm thinking my voice up properly. Yeah. Okay, good. So, in my day job, I work at Fossa, where I write software to hunt on vendor dependencies in your projects on your behalf. In particular, I spent a couple months working on automated scans for AOSP for the Android open-source project Mono repo. So, I'll make a couple references to AOSP as an example throughout this talk. So, to start us off with an overview of what we'll actually cover. First, I'll look at the current state of open-source compliance and automation. Then, what exactly is a Mono repo? Why we care about them? Then, the challenges that Mono repos present. Then, take a slight detour into build systems and how they interact with Mono repos and Mono repo automation, and then wrap us up with the evolution of AOSP of the Android open-source projects built system through time. So, open-source software compliance and automation. Right now, open-source compliance has four main steps. First, you need to figure out what your dependencies are. So, what your actual projects that you're relying on, what their versions are, both your direct and indirect dependencies. So, if your dependency has another dependency that it relies on, you need to know those. Then, you need to look at how you're actually using them. Is it something you're using for just testing in local development? Are you running it in production? Maybe you're packaging it up and distributing it to customers. Third, you need to take each dependency and then look at the risks associated with it. So, is there a copy left license that affects how you can distribute it? Is there a security vulnerability or concern? And then fourth, once you have these pieces of information, you know what your dependencies are. You know how you use them and you know the risks associated with each one. Then, you need to actually identify your mitigation steps. So, maybe you need to stop using a dependency or you need to be distributing your source code properly. Maybe you need to reference it on a distribution notice, whichever that is. So, doing this manually really, really sucks, as you can imagine. There are a lot of dependencies in most projects. There's a lot of repetitive time consuming lookups that you need to do. And in particular, even if you get all of this figured out, you know all of your stuff. And then, a developer goes in and changes the version of the dependency that you're using. They add a new dependency or maybe there's something that they've been using this entire time. You've looked at it, you go, all right, they're only using it for testing. And then, they start distributing it within your distributed binaries and you go, yikes, I needed to be aware of that. So, what if we could automate some of this process? The good news is that we can automate some of this. And in particular, I hope many of you already are. So, the first three steps specifically are what is easy to automate. So, easier to automate. So, you identify your dependencies, how they're used, and the risks associated with each one. The fourth step, so actually knowing what you need to do about all of this information, you do still want an engineering professional or a legal professional to look at it and make that final decision. So, if automation's so great and it makes this process suck so much less, why aren't we automating everything already? Well, automating has a cost. So, specifically, each type of project requires an automation that's specific to its build system, to its dependency management system, to its file layouts, to its naming conventions, and so on. And each time you change one of these characteristics, you need to either create or alter your existing automation for it. And this can add up, and engineers are expensive. So, right now, a lot of people will use an existing external source. So, that's what my company, Tofasa, does, or they'll home grow their own systems. You'll do part of it manually. You'll have some sort of script that works, but this can be messy and error-prone. So, how does this automation process interact with MonoRepos? And what is a MonoRepo? Well, Mono, historically, we've used PolyRepo setups. So, historically, you've had one code repository and then one project per code repository. And then, because of this, it means each project tends to be very individualistic and distinct. Whoever's working on it goes, well, this is the way I want it to be laid out. They decide that. They decide their build system. They decide how they handle dependencies, and so on. And when one of these projects uses another project, it'll pull it in in some way. So, a developer might copy, a recent release into their project. They might download it during the build system. Maybe they'll just copy the other project source code in. A MonoRepo, in contrast, moves away from this. So, in a MonoRepo, you have a code repository. And this code repository contains multiple projects, often related projects. And because these projects live in the same place, engineers look at them and go, well, there's a project here already. I'll make mine look similar. So, they'll use the same build system. They'll use shared infrastructure, shared libraries, and so on. And importantly, if you have projects in a MonoRepo that rely on each other, it's fairly common for them to be able to import resources from one directly, and you can see these relationships within the code repository itself. MonoRepos have become a lot more popular recently. A lot of large companies have been known for using them. Facebook, Google, and Uber are the big three examples I have that come to mind. So, we know why we care about automation. We know what a MonoRepo is. Why do we care about them together? Well, probably, repo projects require a lot of work to automate. Like I said before, when you create an automation, that automation has to be specific to a project's build system, to its dependency management system, to its naming conventions, and so on. So, if you have a bunch of different projects, you may need to create like a new distinct automation for each one of these. And that, as I've said, is expensive. In contrast, if you have a MonoRepo project, they tend to, the projects within the MonoRepo, they tend to be a lot more similar. So, they'll have a shared build system, they'll have shared dependency management system, they'll have shared file structures. And this happens because engineers often default to match existing conventions. If you have a project already existing with a build system, and you can take five minutes and add on to it, or you can set up your entirely brand new build system, it makes a lot of sense to just use the one that already exists. And the other reason for this is that if you're working on multiple projects, it's a lot easier to swap between different projects when they're more similar. So, if you know, oh, this is where the files are always laid out in one project, you can just go over to the other one and know where all of the files are or know how the build system works. So, this is good for engineers, they like it, and it's also good for the purposes of automation, specifically because the key characteristics that your automation relies on tend to be a lot more similar. So, the build system behaves the way you expect it to. The test files are in the same place where you expect them to be, all of your externally published packages follow the same format and that type of thing. And so, because of this, we can reuse the same automation. So, to be clear, it's not that a specific project within a Mono repo is easier to automate in and of itself. It's that the projects within a Mono repo can often share in the same automation or the same work for automating rather than having to do it individually for each specific project. So, if Mono repo projects are a lot easier to automate, why are we here or why am I saying that Mono repos are actually interesting or hard to talk about? Well, Mono repos actually do have a second piece to them, which is their granularity, or rather, you need to have a lot more, a more granular detailed understanding of how the projects within your Mono repo work. So, in particular, your dependency graph for your Mono repo is a lot more important because if you have one small project in a repository somewhere, you have your list of dependencies, you can just look at all the dependencies, say, yep, all of these dependencies they tie to like the single output of this project and you know exactly how those dependencies and how that output is being used. You know if your project's being distributed, if it's like testing, if it's running in your own production instance, whichever. But in a Mono repo, you can't just take the global list of all of your dependencies and say, yep, all of these dependencies are used in all of these projects. So, for example, let's say you have a copy left dependency in your Mono repo, which means any projects that use that dependency need to have their source code distributed. But then you have five projects in your Mono repo and one of them you really, really don't want to distribute your source code for. Then you need to know if it's using that specific dependency or not. And similarly, you don't want to like pull out a dependency that's being used in a safe manner if it's only being used in one project. You want to be able to leave it as is for that one project. This also makes both automation harder and it also makes like manual analysis a lot harder because as I've said before, you have a lot of dependencies per project. So if you have a hundred dependencies, you can sort of work your way through the manual and go through by hand and it'll be tedious and it'll suck that you can do it. But let's say you have 2,000 dependencies or 5,000 dependencies or 10,000 dependencies across your project. It's not just that it's hard to do, it's that there is no reasonable way to do that manually and not be making mistakes and keep up with that workload and not have all of your like engineering team or legal team leave because they're really frustrated about having to go through that process. So yeah, so MonoRepos are harder because you need to have a better understanding of your code base and dependencies and because they're a lot larger so you can't just use the same systems or strategies that you've used. The unfortunate news here is that most out-of-the-box automation systems don't actually support MonoRepos. So you can do a strategy where you say, all right, I know these are the types of projects. I use this tool for my PolyRepos setup where I have a single project. Let's just run it across the entire MonoRepo and you'll get your dependency information but you won't know which dependencies necessarily relate to which projects. So it's not quite as useful to you there. Oh, quick break for water. All right, so I'm going to walk through an example with AOSP now with the Android open source project or a general layout that's common in most projects. So here we have a file tree here. We have a folder A, in folder A you have B and C. B itself has a notice file like a legal piece of information and it also has some source code B. In folder C we have notice file C, source code C. So you know that the notice file and B and the source code and B relate to each other and similarly the notice file and C and the source code and C relate to each other. Second, we know that the source code and B actually uses the source code and C so it depends on C or it imports C. So now we have two pieces of information. We know this dependency graph information between B and C and we also know which notice file relates to which source content. So we need to be able to take these two pieces of information and know that the notice file for source code B relies on the notice file for source code C or should contain the same content from there. So that's the general overview of MonoRepos and automation. I'm going to go into a quick aside on build systems and MonoRepos and how those also affect automation. So not all build systems are created equally or behave in the same way. They have, all of them have different trade-offs which can make them better or worse in different situations. So the first type of build system is an imperative build system where you give instructions on how to run a build. You tell your build hello. Here is like a set of tasks. You go through step one, step three, step three and then the build system goes and actually does those tasks in order. You can be compared to a recipe. So you go, hey friend, I want an omelette. Here's an omelette recipe. Your very lovely patient friend takes a recipe and then they take the steps. They do step one, step two, step three, exactly as you've said and they make you a tasty omelette. The second type of build system is an artifact-based build system or a declarative build system. In this type of build system, the system itself, you describe the shape of your build. So you say, this is the things that you go into something. These are the binaries or the results that we expect out of it. And it can be compared more to a menu where you know these are the ingredients going into your omelette and this is what an omelette looks like. And taking the same analogy as before, you go to your lovely friend who's very generously willing to cook for you. You say, hello lovely friend. Here are some eggs, here are some cheese, here are some green onions. Please make me an omelette. Friend knows what an omelette looks like and they figure out the steps themselves. So to be clear between imperative build systems and declarative build systems, it looks a lot like a spectrum. So build systems vary from like very imperative to like almost declarative to actually being declarative. But a build system is explicitly one or the other. It can't be both. So two examples of this are make or make files which are strongly imperative and basal build files which are strongly declarative. So I do care about build systems. Why have I brought you all here to listen about Monoripo Automation and then started talking about build systems? Well, there's a relationship between the type of project that you have or the type of like repository layout that you have and the build system itself. So in a poly repo build system, each project can use whatever build system it wants. It can be imperative or declarative. It just depends on whoever's working on the project and what they prefer and what your needs for it are. But in Monoripo, say almost always use declarative build systems. And the reason for this is that declarative build systems work a lot better on a massive scale in general. So for example, if you're working on the scale of an omelet or three ingredients, it's a five minute process. It doesn't really matter how you do things. But let's say you go to your very lovely, very patient friend and say, hey friend, I want you to make me a five course meal. You're going to make me macaroni and cheese and pizza and nachos and omelet and this and that. They want to be able to take all of the things that they're doing, all of the food that they're making or all of these like build artifacts that you're building and like reorder or like optimize this. And because they know what they're doing and they have all of this flexibility and freedom, they can build, they can like cook or they can like build your build system in a more efficient way or in a more effective way. So once again, why do we care? This is tied back to automation. Well, imperative build systems are really, really hard to analyze with automation. And in general, you pretty much have to run the build itself in order to see what it's actually doing. If they can depend on like environmental dependencies, they have complex control flow. And in generally just like I said, you can't statically analyze them. There's an urban myth floating around at work about someone who ran into a make file where this make file invoked a curl command that curl command went to some university professors website, pulled down some C and C plus plus source code, compiled it into the build and then deleted the original like source files.  In contrast to that, a declarative build system, the type of build system that is almost always used in monorepils tends to be a lot easier to analyze with automation. In particular, this is because the build system is responsible for its control flow.  And so this means that certain aspects of the build can be statically analyzed. In particular, you should be able to look at like relationships between different pieces of code or different parts of your project and know which ones are used by which other ones because that's what you define within your build files and that's what the build system just like takes that information and puts it together. But you don't need to run the build to necessarily know all of this information. So because monorepos tend to use declarative build systems, they tend to be easier to automate because of that. This isn't guaranteed. I'm sure there's some monorepo out there that uses an imperative build system. The maintainers are very happy with it and shaking their fists at me right now. But in general, monorepos do have to use declarative build systems. So now I'll wrap this up by looking at the AOSP monorepo, the Android open source project monorepo and how its build system has evolved over time to sort of prove or give a good example of this tendency of monorepos to use declarative build systems. So AOSP initially started off as like here's a big collection of projects that are stitched together.  Most of the projects already used like make files or make as its underlying build system. So they continued to do that. And then this started to break down as a project got larger. It became error prone, it's hard to debug, it's hard to maintain those. They're hard to test. And so AOSP started to move towards Android make files, which are like make files, but a little bit more structured, a bit more declarative. And then once again, this started to break down. And so AOSP started to move towards the song build system using like blueprint files to define your build. This is again, much more declarative than before. But AOSP is like I said, it's a monorepo and it's a massive monorepo. Right now they have over 300,000 files. And I think it's something like 200, 250 gigabytes to be able to build it yourself. Like that's really hard to take 300,000 files and figure anything out of that. And it's also hard to instantaneously swap from one build system to another. So right now they're wrapping up being in a hybrid state where they have Android make files which are fed into Android make and then converted to a Ninja file for the Ninja build system. So that was the old type that still exists. And then they have Android blueprint files which are fed onto the song build system and that generates Ninja files which go into the Ninja build system. And then that compiles it. So this is like a fairly complicated system to look at manually and know how things relate. It's also really hard to look at in an automated way and know how things relate because you need to understand like so many pieces. You need to know how Android make works. You need to know how song works. You need to know how Ninja works. And you need to be able to get the pieces of information from those three systems and like actually stitch them together. So like I said, this is an example of a massive monorepo moving towards a declarative build system. So we started off with make files which are very imperative. Move to Android make files which are less imperative and moving to blueprints or song which is less imperative with Ninja as a sort of hybrid. And they've actually announced right now that AOSP is moving towards a basil build system, a fully declarative build system who is, it is like a very common build system for monorepos and it's like becoming adopted much more frequently right now. So like I said, clear progression from imperative build system to declarative build system for monorepos and a clear progression from a really hard to automate type of build system to much more manageable to automate build system. So to give a quick recap, open source compliance requires a really good understanding of your code base. You need to know what your dependencies are. You need to know how they're used. You need to know the risks and mitigation steps. And you need to be on track of like any changes that happen within your code base. And so we really want to automate this. However, automation needs homogenous projects to be effective and to get like a good payoff for the amount of work that goes into the automation. And so monorepos are like both a challenge because you need, it's much harder to get this granular in-depth understanding of the code within your monorepo but they're also an exciting opportunity for like automation because the projects are more similar so it's more manageable to automate them. And because we now have a lot more information on the relationships between the projects in your code base so you can understand them a lot better. I'd like to give a special thank you to my manager and mentor Eric Morris for his help preparing this talk. And also list off a couple of resources that I found really good. In particular, the book in software engineering at Google lessons learned from programming over time is excellent and they have a very, very good section on build systems in particular on Bazel and its evolution and how they've reached that and all the cool things they're doing there. And then the Fossa blog itself has a couple good articles on monorepos and on automation for license compliance. Then does anyone have any questions? Yep, so going over why imperative build systems are harder to automate, I will back a couple slides so I can point at it. So in an imperative build system, it's usually, you have like a set of steps where you'll say first do this, then do that, then do whichever and they tend to be very, very flexible. So you can tell your build, I have a warning, I'm sorry, how much is that? Thank you. So if you have a set of steps, you can do very much whatever you want with them. So you can, the example I think I gave was there's this urban myth of someone who's like has a bash command within their build system where it just downloads source code, builds it and then deletes it afterwards. So unless you're actually like walking through and looking at what it's doing, you can't quite tell. But there also tends to be a lot more flexibility in terms of how your build system files themselves are structured, so you can lay them out, you can order different things, you can have different naming conventions. In declarative build systems, you don't really have a set of steps. You just sort of have a list, like you'll have like a module defined where you say this is my list of inputs, this is my list of outputs and the build system, it's all sort of figure it out. So it's in general, they often do the same types of things and you can find a way to make declarative build systems and imperative build systems behave in sort of similar manners. But declarative build systems always push you towards like hey, define your structure with inputs and outputs whereas imperative build systems are like, oh, go figure it out yourself, do whatever you want. So they tend to be less standardized too. Thanks for that. Yep, repeating that back for virtual listeners sounds like Monoripos are a lot easier to automate or a lot better to automate because of these declarative build systems. Hi. Hi. Has the use of Monoripos changed your processes around branching and merging and pull requesting? Oh, yes. So I've worked with Monoripos at, I worked with the massive Monoripo at Facebook for a while and they had to build up this entire system around just getting any of your code in because when you have like thousands of people who are trying to get a commit merged in any hour, everything just breaks down and a lot of like automated testing on merges breaks down and stuff gets really slow and it's a little bit of a pain to work with. On my current job, we use a very small Monoripo where we have I think four or five projects inside of it and that hasn't had major impacts on us yet. Our pull request process is still the same. We have had to define different ways for engineers to handle code review. So specifically saying like, hey, we have this like round robin, we have this setup for picking code review on this project or picking a reviewer on that project. But it does tend to be, yeah, otherwise it's fairly similar for the smaller Monoripo and for like individual projects there. I think it can be very dependent on your team and on your project setup and just generally what you're working on. So you're aware of any changes to your process instead of doing a Git flow, like a modified Git flow for Monoripo or something like that? Yep, so I don't have any good resources off the top of my head. Yeah, I don't know any off the top of my head. Any further questions?


Good afternoon and welcome to news on the go with me Darius Jrna and we are broadcasting to you live here in oudlands the resident of kawata member of parliament levi mkandawire who has since died after being hit by a moving vehicle just right here where i'm standing outside his premise so far as i speak to you there are quite a number of the party members that is from the upnd who have come here to offer their solidarity and among the people that have come here is a party deputy secretary general but i'm getrid imenda who is just right here besides me i will talk to her right at this very moment just to confirm this particular sad development good afternoon mam your live on demon tv news on the go good afternoon Darius they need to be protected our leaders need to be protected that's all i want to say no according to the nation that you can ask that you went to the motor and also you came here to see no but the accident according to the information that you have would you brief us what you know that had transpired what has transpired is that this kiyaku was coming from mister okay mr kandawire on the kandawiri had the pact he's the he's the able to hear and he was going to open the gate this kiyaku from nowhere just came and just hit him and came to hit this excuse me came to hit it to hit this fence here and it is this it is this concrete block here which is ferro you can see the flag there huh maybe we will try to move closer in the mortuary i saw i saw his head he had been hit uh this side this is the this is that that part you see the blood there it hit him this side god knows maybe the chest and so on so that's why it was meant that he should not survive i don't want to believe that it was a miak state because what speed was the person what he said the the brexit failed why was it entered to the brexit failed when uh under the kandawiri was opening the gate no i don't want to believe that and i want the police to go to the bottom of this thing if this police is still police men still belong to the pf let them treat that man with kid gloves but otherwise no i appeal to the police command let them take this matter very serious we are not safe our mps are not safe our leaders are not safe what you're saying madame is is that he had walked his car and walked out of the car he was bashed when he was outside the gate he was trying to open the gate and he was bashed outside the gate so the vehicle had to be wrapped into in some kandawiri's vehicle and it moved to kandawiri and up to this place where kandawiri was come again the man hit me some kandawiri he hit the vehicle he hit the vehicle first at the back in some kandawiri then the same vehicle came now the the the assassins vehicle i'll call him that came to hit him here hit here and then that's how the office that's how the office thank you very much for where was he coming from okay all right that's the upnz deputy deputy secretary general there i'm madame gertrude amenda just narrating to us what she has heard as regards to what transpired here and according to the information that we have received right at this very moment is that mistam kandawiri was just hit there um well i am just pointing at as he was trying to come out you know from his yard let me talk to the upnz media director tabukawana was also come here the residents of mistam kandawiri i would have to say it's a good afternoon in this moment of shock i lost my words and here i pass my future kandawiri since family of one of them kandawiri we got the news about the accident and uh we came here to see for us and i think what is happening is like we have seen fresh in the road itself this is a speed limit of 30 to 40 kilometers per hour this is a smooth street but if you look at the impact it shows you that one would not be far from the truth if one suspected that this was an assassination attempt but we will not speculate we will leave the matters to the police to be able to investigate or do their job and when they come up with a conclusion now let us know but we remain shocked we remain fearful we remain lost for words but at the same time we remain complaining because we cannot understand how a vehicle in this street which is in a residential area could be driving at such a high speed and missing all targets but clearly getting off the road and targeting our our member of parliament here to a point where the crash looks like it was intended to ensure that when they hit him he can't survive the crash and this is what has happened so we are shocked really we are shocked we are saddened by these events but we leave it all in the hands of the Lord we also leave the official communication as far as what transpired to the police to do their work and they will tell us what they would have found all right thank you so much Mr. Tokawana for having an interview with us thank you very much okay Mr. Tokawana there who is the UPND alans media director also giving us an interview as regards to what transpired according to what you know the people the UPND you know members are saying here they are actually alleging that this could have been an you know a suspension attempt but we do understand that the driver who was arriving the vehicle has since been arrested and the police have actually began to give interview and investigating rather this particular you know science development that occurred good evening this is the honorable Levin Kandawire speaking I'm alive as you can see from the video there's a fake news that has securated on social media I want to confirm and affirm that Levin Kandawire is alive very much alive as you can see from this video thank you very much he has died I'm telling you my husband is just from calling me


Alright, let's move on. Let's get to the arguments against scientism. These are actually not that easy to find in a literature, so I've been working on them myself. And what I'll do is present three versions of, three different kinds of arguments against scientism and then also have a look at what kinds of replies adherents of scientism could give to them. So here we go. Here's the first argument, and I've called it the fundamental argument, unpretentiously, but we'll see in a minute why it's called the fundamental argument. The basic idea of the argument is that, sure we can do science and surely it provides knowledge, but science itself is based on things that are not science and science can provide knowledge only if those things from which it starts count as knowledge. So the things I have in mind here are such things as perception, of course, so I know that there is a microscope over here because I see one, but also memory. So I remember that this DNA sample is the same one that I used yesterday. There's introspection, so I know that I intend to carry out this experiment tomorrow. I know what I believe about my previous experiments. For instance, I know that I believe that I should redo this experiment. If all those sources that science is based on do not count as knowledge, then natural science itself cannot provide knowledge. So that's why it's called the fundamental argument. If science provides knowledge, it can only do so because non-science can provide knowledge. What response could one give to this? Well, the first response is to say, this is kind of a partial defense, is to say this may be true for the five senses, so vision, for instance, and also memory, it may be introspection as well, but it's not true for morality and it's also not true for religion because we do not appeal to moral beliefs, we don't use moral beliefs and we don't use any religious or supernatural beliefs in doing natural science. I think that's definitely going to be true for religious beliefs, but it's also true for moral beliefs is an interesting issue. I'm not going to debate it today, but I just wanted to point out that this is a reply adherents of scientism could give. Another interesting reply that one could give is the following. It appeals to an example that's often used in philosophy, which is the ship of Theseus. So it's often used as an example in metaphysics. Theseus has a ship that consists of 365 wooden planks and he sets sail and he leaves harbour and he has another 365 planks on board. And what he does when he is out there at sea is he replaces one plank of the ship every day and by the end of the year every plank of the ship has been replaced with a new plank. So in a way we have an entirely new ship. And you can imagine that the old 365 planks are destroyed or a new ship is made out of them or whatever you like. The question is, is this still the same ship or is it a different ship? So this is a topic that is discussed in metaphysics. It has to do with identity over time. But the interesting thing is that this example can be used for the issue at hand. So to meet the fundamental argument. And people like Neurat, whom I think I mentioned earlier, have actually used it in defence of scientism. So what they say is this. Look, you can't replace everything at once. You can't replace the whole basis, the whole fundament of science at once. But you can replace one particular non-scientific thing with a scientific thing. So here's a belief that science is based on. Let's scrutinise it by way of natural science. And if it's not correct, let's replace it. And if it's correct, then it has passed the natural scientific test. And then let's move on to some other place. And if we do that long enough, we can verify or if necessary replace all the fundamentals, all the bases of science. So natural science is indeed based on certain non-scientific things. But if we do thorough checks all the time in the end, it will no longer be the case. So this is a reply that one could give. Well, this raises lots of philosophical questions. For instance, one can't start from nothing, right? One has to use something. One has to rely on one's memory and one's visual perception when one starts. Of course, one can return to that memory and to that visual perception later on. But isn't it the case that if the beliefs that one started with were irrational, that that property is conferred to those later beliefs? That's a question that needs to be addressed. So there's a lot to be said here, but I just wanted to point out this is an important argument that opponents of scientism have levelled against scientism. The fundamental argument, at least that's how one could call it. Let's move on to the second argument that is often called the argument from self-referential incoherence. Arguments from self-referential incoherence are often found in philosophy. So you will find them, for instance, when it comes to certain kinds of reductionism or when it comes to certain kinds of foundationalism in epistemology. I'll leave the discussion of those for another time. I just want to apply it to scientism in this particular case. So the basic idea is that scientism is in trouble because the thesis of scientism, so the thesis that only natural science provides knowledge, is itself not an instance of a product of natural science. So the thesis doesn't meet its own criteria. It's not something that we believe on the base of natural scientific research. Hence, we cannot rationally believe and we cannot rationally embrace. We cannot know that scientism is true. But if we cannot know that scientism is true, then why should we believe it in the first place? That's the move one could make here. Now I believe that there are several responses available to the adhering of scientism. Those responses are going to be controversial, but I would like to mention them here. Because I think these are options that the adhering of scientism needs to explore. First, one might think that there is scientific evidence for scientism. So one might think that, well, there is the success of science that I mentioned. And then there is also science that supports debunking explanations that I mentioned earlier of non-scientific sources of belief. So there is enough evidence to think that science provides knowledge, whereas non-scientific sources of knowledge do not. So one might think, look, scientism itself, in the end, is supported by scientific evidence. There's a lot to be said about here because scientism is still a claim about knowledge. So one needs to have a certain idea about what knowledge is or what rational belief is. But rather than delving into those physiological questions, I will move on. Second one could say, look, scientism works. It's just a really good theory and a really helpful theory in carrying out science. And here, again, discussion is possible. So one might say, well, scientism works in doing science, but then other theories work equally well. So if you have a theory that says science provides knowledge, but other sources of belief also provide knowledge, such as memory and introspection and moral intuition, that works equally fine. I can do my scientific research equally well if I don't embrace scientism. So this reply is going to be controversial. An equally controversial reply is going to be the reply that says, scientism is true and we should make an exception for scientism itself. So something counts as knowledge only if it's based on science, except for the thesis of scientism itself. That is a piece of knowledge, an instance of knowledge, even though it's not based on natural science. That's what one could say, but of course this is going to be controversial because it seems so ad hoc, right? Why make an exception only for scientism itself, on what basis? So maybe the most promising reply is the final reply that I'm going to mention, namely to treat scientism not as a claim or as a statement, but as a stance. The idea or the concept of a stance has been developed in some more detail by Bas van Vraassen, the Dutch American philosopher of science, who has written extensively about empiricism. So he claims that empiricism is a certain stance and not so much a thesis or a claim.  So it's not merely a claim, but it's something broader and also something deeper than that. And this is an idea that some adherents of scientism embrace. An example is James Laderman. So James Laderman has defended a restricted version of scientism, namely scientism about metaphysics. And he says, look, we should treat scientism not as a thesis, but as a stance. It's a particular attitude one takes. And because it's an attitude that one takes, it does not suffer from the problem of self-referential incoherence because it doesn't claim that scientism itself is a case of knowledge. This is an interesting suggestion, but also a challenging one. Because if it's not a case of knowledge itself, but merely a stance, then how are we going to judge whether we should adopt this particular stance so that a scientific stance, rather than another stance, a non-scientistic stance, on what basis are we going to evaluate which stance we should take? What are the criteria? And it seems to me that this issue is not yet developed enough in the literature to see where this is going. But it seems a potentially promising route to take for those who want to claim that we should all embrace scientism, but that it does not suffer from problems of self-referential incoherence. And this brings me to the final argument that I would like to mention against scientism. And I call it the argument for non-scientific values and principles in science. And you will find certain aspects of this argument in the work of Michael Stanmark, the Swedish philosopher of science and Swedish epistemologist. So he has written quite a bit on scientism. He's one of the first philosophers, I think, to write extensively about it. And the argument is basically this. If we do science, then we look at different scientific theories and we compare them with each other. But we do so on the basis of certain criteria.  One of them is precision, right? How precise is this particular theory that we have over here? Or how precise is that one? Second, it's explanatory scope. So how much does it explain? We generally prefer a theory that explains more to a theory that explains less. Third one is explanatory power. So how well does it? How well does it explain the phenomenon at hand? Fourth, simplicity. We generally prefer the theory that is simpler, so that is committed to fewer entities. So the simpler a theory is, the more likely it is that it is true. A fifth one is, of course, coherence with background knowledge. So we want theories that cohere with what we already believe or what we already think we know. Another one is fruitfulness. So some theories can actually be fruitfully employed in further research, whereas other theories cannot. Unifying power. I already mentioned evolutionary theory that has great unifying power. So it takes all sorts of theories and ideas and observations together and explains them in one grand unifying theory. And the final one is elegance or beauty. This is important for in mathematics. So mathematicians say they often prefer a theory because it's more elegant, it's more beautiful and have some trouble spelling out exactly what that amounts to. But at least it's one of the virtues theories can have. Now here's the point. So if you look at this long list of virtues of criteria for selecting theories, then one makes a choice in favor of one theory and against another theory based on balancing those criteria. But the balancing of those criteria is not something one can do on a scientific basis. So there can be two scientists who have the exact same data and the same background knowledge. But they come to embrace a different theory because the one finds, say, simplicity more important, whereas the other finds explanatory power more important. And what this shows is that within the science itself, so within the scientific practice, there are core values that are not themselves scientific and that we can't judge on the basis of scientific research. So this is a challenge for a scientism itself. Given that there are non-scientific values that play a crucial role in scientific research. So these are three arguments against scientism and maybe they can be met, maybe they cannot be met. I think this is a topic that will receive much more scrutiny in the nearby future.


What's going on everybody welcome back to another draw preview and we have a massive WTA 1000 event in Dubai this week, and it's got some big names playing this feels like a mini grand slam But unfortunately we've got a lot of names out. So let's go to the withdrawals So starting at the top of the withdrawals we have Andrescu.  All right, let's go to the top of the draw There are 16 seeds in this event the top eight seeds get a buy in the first round and the number one seeds Fetalina she gets a buy in the first round she'll buy the winner of Wang versus Kuznetsova in the second round So not an easy start there force Fetalina Then we have Teague versus Osta Penko winner that's gonna play the Krajikova Well, the number 16 sees Sakari in the second round and we've got the number 11 seed keys She gets a qualifier in the first round the winner of that match is gonna play either Sigermond or Potapova in the second round Then we have Pavlechenkova versus Kudamatova in the first round battle of the Russians winner That's gonna play against number six seed Benchich in the second round So a lot of informed players at the moment in this part of the draw This is not an easy draw especially for someone like Fetalina who is representing as the top seed in this event Even though she's the number five ranked in the world. She's the top seed a lot of pressure on her She's gonna have to play players like Sakari Kuznetsova might be her second round opponent and Benchich She's doing okay at the moment as well. All right second part of the draw We have number four seed Kovinova who just won in Doha last week So she's in some form she gets a buy in the first round She'll have the winner of Bodosa versus Taikman in the second round Then we have Jabor versus Sinyakova winner that's gonna play either Zheng Well the number 14 seed Rybakina in the second round Then we have the number 12 seed Vondrasova gets a qualifier in the first round winner That's gonna play either wild card Goff or Alexandrova in the second round So Goff she gets a wild card into this event We all know that Coco is very dangerous as an unseated player There may be a qualifier versus Plishkova in the first round and this is the sister of Plishkova Of course winner of that match is gonna play against number five seed Bertens in the second round So Kiki Bertens coming back from injury still trying to find her feet though Because she didn't play well last week So she's still on the comeback trail and hoping to get a couple of wins this week But the standout name for me in this one is clearly Kovinova She's in form and she's played well in these conditions only a week ago last week she played amazing So she's in form. She's the one to watch. All right, the third quarter of the draw We have the number eight seed Spiontek getting a buy in the first round She'll play the winner of a qualifier versus Hercog in the second round Then we have Anissa Mova versus a qualifier winner of that match It's gonna play either another qualifier or the number nine seed Mugaruta Who I think has been one of the best players of 2021 She made a couple of finals and she also had a match point against Australian Open Champion Osaka as well So it's Mugaruta very unlucky not to have won a title so far this year She is the name to watch out in this event She's full of confidence especially making the Doha final last week and she could be playing Spiontek in the third round, which is a crazy match Then we have Contovit the number 15 seed versus Babos in the first round Winner of that's gonna play the Castella or a qualifier in the first round Then we have Kornay versus Kazakina Winner of that's gonna play against number three seed Sabalenka We had a very poor week last week. She lost in her first match last week She'll be looking to redeem herself in this one And she has a decent draw in the first couple of rounds But then she's probably gonna have to play the Mugaruta or Spiontek after the third round So it's gonna be tough for her But Sabalenka she likes a challenge and she'll be looking to get her form back after a poor week last week Alright the bottom quarter of the draw we have Azarenka the number seven seed who pulled out injured last week in Doha With a back problem. So we'll keep it on her. Her second round opponent will be the winner of Kerber or Garcia So that's a tough second round there for Azarenka, especially if she's not a hundred percent Then we have Rodgers versus a qualifier. Winner of that's gonna play the Ferro or the number 10 seed Mertens who's always a sneaky player, especially when she's a low seed in an event like this Watch out for Mertens. She could sneak through the draw, especially if Azarenka is not a hundred percent Then we have the number 13 seed Martich versus Mladjanovic in the first round Winner of that's gonna play the Svettava or Pagula in the second round and Pagula has been in great form lately So keep it on her. Sevastova versus Perra will play in the first round winner of that's gonna play against number two seed Pleskava who to be honest has been very bad in 2021 She has not lived up to her top 10 ranking at all yet Maybe this tournament is the tournament that she needs to really get herself into that winners column And maybe she gets those championship from this one. Who knows maybe she makes a final I think that'd be a good result and she has a good draw She has no real worries except for maybe Mertens and Azarenka But again Azarenka big question mark after last week getting the back injury So you have it some big names in this one Of course some big names not playing but it's still a stacked event a lot of top 10 players a lot of Informed players as well very hard to pick who's gonna win this one. Let me know down in the comments below Who are you picking to win this event? So looking through all the seeds here? We've got some players that have played really well We've got some players that have had bad weeks over the last couple of weeks But I'm gonna go with Sabalenka because I think Sabalenka after last week having such a poor performance It's gonna come out with a bit of fire underneath her and we'll be looking to get some revenge over a poor week last week So I'm gonna go with Sabalenka who loves to play in these hot conditions again Let me know down in the comments below. Who do you think's gonna win this one? So the Dubai championships the first WTA 1000 event of the year. That's gonna be a good one


When I was born, I was very excited about my life. I was very nervous about my life. We were very happy about our life. I am very happy to be part of this community. When I first came here, I knew that the land was mine. I was very happy that the land is mine. This is amazing. This is the first time I have seen a landmine like this.