WEBVTT 00:00.000 --> 00:05.880 What is up everyone? So today we're talking about KDE Linux and that it kind of represents 00:05.880 --> 00:13.820 something in its own way, kind of genuinely exciting in the desktop computing space as a whole that 00:13.820 --> 00:18.520 I think deserves a little bit of attention. For what I'm always happy to see like a new Linux 00:18.520 --> 00:24.560 distro actually out there. It's kind of like a kid with a shiny new toy. Unfortunately that 00:24.560 --> 00:33.280 attention span sometimes goes with it. But it's really true when it actually comes from people 00:33.280 --> 00:40.100 like this, meaning the KDE team specifically. But this video is still a bit different. Like 00:40.100 --> 00:46.340 I'm not necessarily doing this video because I'm super excited about the distro because I'm 00:46.340 --> 00:50.680 really not if I'm going to be honest with you guys. I'm not going to actually use this 00:50.680 --> 00:59.900 in my daily life. I'm making this video then in turn because I actually know that there are those of 00:59.900 --> 01:08.000 you out there who watch my videos who are hyper intelligent and a ton of the time I actually 01:08.000 --> 01:14.580 get to learn from you guys and I'll tell you my thoughts first on it which is fair and in 01:14.580 --> 01:21.140 exchange I'd love to actually have a chance to read what you actually think about this distro. 01:21.700 --> 01:26.980 And this can be like positive or negative. In fact, I'd prefer to hear both if you actually 01:26.980 --> 01:32.620 want to write all that out. But in any case, let's get right to it. So for three decades 01:32.620 --> 01:39.280 basically KDE has created some of the more sophisticated desktop software that's actually 01:39.280 --> 01:45.360 available that's out there. But users never really actually experienced it. I think the way that the 01:45.360 --> 01:52.760 devs probably wanted them to actually experience it. Every distribution that shipped KDE, no matter 01:52.760 --> 01:59.560 what it was, applied their own kind of modifications and sometimes branding and configuration choices 01:59.560 --> 02:08.920 in other cases. Users essentially wound up with kind of these filtered versions of KDE really. 02:08.920 --> 02:16.860 Instead of the actual like undistilled versions. And this is basically KDE delivering their software 02:17.640 --> 02:23.380 directly to users without any intermediaries that are actually they're like meddling around 02:23.380 --> 02:30.060 and modifying the experience, which is going to be in my opinion, kind of interesting to see. 02:30.160 --> 02:35.780 Because in turn that means there's no more like waiting months for distribution 02:36.520 --> 02:43.160 maintainers to actually package updates or wondering like if that bug exists in the upstream 02:43.700 --> 02:51.280 KDE version or just in your actual distributions version of KDE. And yes, 02:51.720 --> 02:57.240 to its credit, Nome already has its own OS as well with lightly builds. That's not 02:57.240 --> 03:03.040 side issue, but whatever. KDE built an immutable system where the core components 03:03.040 --> 03:10.380 remain protected from accidental damage, but they implemented intelligently in my opinion. 03:10.740 --> 03:17.700 Now the system caches like five previous versions. So basically, if an update creates issues, 03:17.700 --> 03:24.400 you can instantly roll back without reinstalling or troubleshooting for hours, which 03:25.380 --> 03:30.460 is definitely cool. Basically, your own directory remains completely under your control. 03:31.000 --> 03:37.240 Software installation works through multiple methods that exist from Flabpack, which provides the kind 03:37.240 --> 03:44.760 of primary mechanisms, but snap and app images and containerized environments through distro box 03:44.760 --> 03:50.160 and toolbox also give you pretty extensive options for running whatever software you 03:50.160 --> 03:56.940 actually need to have development advantages with KDE Linux also exist here. Developers 03:56.940 --> 04:03.640 working on KDE software save something like 45 gigabytes of space compared to traditional 04:04.120 --> 04:10.640 source building kind of setups build times, therefore also decrease pretty dramatically, 04:11.100 --> 04:17.300 because you only compile specific opponents that you're actually modifying in that case, 04:17.720 --> 04:24.380 rather than like the entire dependency chain. Now most important for developers anyways is 04:24.380 --> 04:29.620 that they can test their code in the exact environment where their users will actually run 04:29.620 --> 04:35.080 it. And this eliminates those kind of frustrating bugs that basically only appear in specific 04:35.080 --> 04:43.020 configurations. The technological choices that we saw in KDE Linux in some ways are forward 04:43.020 --> 04:49.680 thinking, I would say in terms of engineering, Wayland, which whatever you want to say about 04:49.680 --> 04:56.220 that in a lot of cases does provide superior security in a few ways and performance to boot 04:56.220 --> 05:02.600 compared to legacy x11 systems and when it works that is and I don't want to give 05:02.600 --> 05:08.420 too many for that in the comments. I don't care. I said it anyways like Wayland 05:09.620 --> 05:17.540 has constantly been ready and almost ready for like almost a decade now. So whatever like 05:17.540 --> 05:26.780 I can I can say whatever I want about it. Anyway, pipe wire handles both audio and video streams 05:26.780 --> 05:34.380 through a unified modern kind of architecture and btrfs, which is a file system for those of 05:34.380 --> 05:41.380 you that don't know, enables automatic snapshots, compression and really efficient storage 05:41.380 --> 05:47.540 management, which that I really cannot say enough good things about in all seriousness, 05:47.800 --> 05:51.380 like if you don't know what that is, you should definitely check it out, especially if like 05:51.380 --> 05:56.880 you're using like time warp or whatever like it's really it's really cool system de integration 05:56.880 --> 06:03.680 also is great for service management and updates as well. All of these kind of really 06:03.680 --> 06:10.300 cohesive modern platform built with current technology versus maintaining compatibility 06:10.880 --> 06:19.140 with systems from the 1990s, which I get it it does make sense that again like I also really 06:19.140 --> 06:26.380 like ex Libre for more than a few reasons that you can see if you want to look it up on this 06:26.380 --> 06:30.700 channel I have a whole video on it. Anyways, unlike the tour project this volunteer driven 06:30.700 --> 06:37.800 project operates without advertisements data collection or hidden costs and its volunteer 06:37.800 --> 06:44.280 run, which should earn them a fair amount of respect and I'm right off the rip. KDE has spent 06:44.280 --> 06:51.300 like 30 years basically creating free open source software and they're applying all of that expertise 06:51.300 --> 06:57.680 to this operating system and its development in general from what I've seen. The development 06:57.680 --> 07:05.820 process remains completely transparent with clear funding through KDE, EV and community 07:05.820 --> 07:14.060 contributions. Now, multiple planned additions kind of accommodate whatever your use case really is 07:14.060 --> 07:21.860 right so like different user needs can be adapted intelligently based on whatever one you end up 07:21.860 --> 07:27.440 picking. So for example, there's the testing addition, which provides daily builds from 07:27.440 --> 07:34.440 development code for Q&A testers and developers who actually want immediate access to the new 07:34.440 --> 07:42.260 coolest features and the enthusiast addition kind of targets power users with beta and stable releases 07:42.820 --> 07:50.280 following KDE's actual development schedule and stable addition will more or less serve users who 07:50.280 --> 07:56.360 prioritize things like reliability over the like cutting edge bleeding edge kind of 07:56.360 --> 08:03.480 features that we see or the other additions. So basically like whatever box you belong to 08:03.480 --> 08:09.700 they try to sort you into whichever one that you should be it and the atomic update switching 08:09.700 --> 08:16.860 between additions seems to be completely safe. So developers can use testing additions during 08:16.860 --> 08:22.800 active development periods then switch to stable additions when focusing on productivity 08:23.680 --> 08:30.220 without risking system stability or whatever. Now hardware support follows a kind of simple 08:30.220 --> 08:36.440 batteries included type of approach. What I mean by that is that it has really extensive 08:36.440 --> 08:43.900 driver coverage to say the least and these get preinstalled more or less so that you have maximum 08:43.900 --> 08:51.320 compatibility right. Things like modern NVIDIA GPUs receive preinstalled open kernel modules 08:51.320 --> 08:58.980 and user space drivers which in turn provides a kind of fairly seamless functionality in regards 08:58.980 --> 09:04.680 to like other operating systems that are out there. We have to do it all like manually 09:05.480 --> 09:11.460 which can suck. By doing that they basically make it so that users have to worry less about 09:12.340 --> 09:18.980 screwing up but more or less the alpha releases primarily geared towards like devs and 09:18.980 --> 09:27.280 hardcore enthusiasts that alone kind of shows the KDE as a community as a volunteer community 09:27.280 --> 09:34.880 have their commitment to quality over say rushed rubbish releases right and if you grab it you 09:34.880 --> 09:42.120 should keep that in mind. Also keep in mind like this is an alpha release right. So what are some 09:42.120 --> 09:47.320 of the known limitations. So from what I saw there are some rough edges in some of the 09:47.320 --> 09:53.820 applications. I think it's missing secure boot but don't quote me on that and the manual 09:53.820 --> 10:02.440 configuration requirements for say older NVIDIA hardware in other words it's kind of like your 10:02.440 --> 10:09.480 regular alpha stage limitations. Another thing that I found was that supposedly if you reviewed on the 10:09.480 --> 10:15.100 site they're like oh like we don't support virtual box like you can't run this in a virtual box. 10:17.020 --> 10:20.320 They said that on the site I think or maybe they said it somewhere else 10:20.320 --> 10:28.380 but I saw it and I didn't like it so like I figured out a way to run it in virtual box mainly 10:28.920 --> 10:35.560 just because I don't like to be told what to do so I did it anyway. So if I still have the commands 10:35.560 --> 10:40.160 for that and how I did it I'll try to pin put in the pin comment if I don't forget. 10:41.460 --> 10:45.260 I'll probably forget so you guys can just yell at me like you did in the other video 10:45.260 --> 10:51.480 like then I went and fixed it either way so it does run but it takes it's kind of hackery right. 10:52.320 --> 10:57.920 But even in like the hackery environment that I had it in with virtual box it worked really well 10:57.920 --> 11:03.340 like it was really fast it was really responsive and that was cool. Anyways one of the cool things 11:03.340 --> 11:11.760 about like the entire thing that KDE basically can now recommend their own operating system to 11:11.760 --> 11:18.420 hardware manufacturers without actually showing like any kind of favoritism towards actual distros. 11:19.180 --> 11:25.060 So direct relationships with OEMs kind of becomes possible along with consistent hardware 11:25.060 --> 11:32.860 compatibility testing and update delivery on KDE's own schedule on like the micro level 11:32.860 --> 11:39.920 of this right users which is the micro level this provides like the most authentic KDE experiences 11:39.920 --> 11:46.720 that you can have without any kind of like modifications or compromises or a particular 11:46.720 --> 11:53.920 distros agenda because a lot of them have agendas which is insane but whatever on the macro level 11:53.920 --> 12:01.560 like downstream distributions benefit from improvements developed from KDE Linux while 12:01.560 --> 12:07.300 maintaining like their own kind of unique value propositions. What I mean by that 12:07.300 --> 12:15.820 is basically because they are running their own OS they themselves will run across improvements 12:16.280 --> 12:24.120 that actually need to be made and in turn will be able to do so which will actually benefit 12:24.120 --> 12:32.180 other users who use their desktop software still by another distros right. So the immutable 12:32.180 --> 12:37.300 architecture addresses a couple of different persistent reliability problems that have definitely 12:37.300 --> 12:42.500 affected traditional distributions package conflicts become basically impossible this way 12:42.500 --> 12:48.640 update failures that leave systems completely broken get totally eliminated the whole like 12:48.640 --> 12:55.640 works on my machine problems between different installations disappear which obviously is huge 12:55.640 --> 13:02.180 however it also means that if you have like any kind of supply chain a check for example 13:02.920 --> 13:10.040 you're totally screwed the volunteer community that actually created this distro basically 13:10.040 --> 13:16.320 really shows us what happens when skilled and motivated people can accomplish when they come 13:16.320 --> 13:22.960 together right when working towards a common goal anyways and the same community that has 13:22.960 --> 13:29.700 refined desktop Linux for decades basically is now applying that kind of expertise to 13:30.440 --> 13:36.200 a complete operating system and the development of that operating system which is going to be 13:36.200 --> 13:42.020 interesting to watch and I for one definitely look forward to seeing what the end result will be 13:42.500 --> 13:48.460 when it's out of beta and it hits that year mark that five year mark future development 13:48.460 --> 13:56.640 includes things like automatic home directory encryption in btrfs based backup systems 13:56.640 --> 14:04.120 with intuitive interfaces now these features will obviously enhance security and protection 14:04.120 --> 14:10.560 but at the same time they also maintain the user's experience quality that people expect 14:10.560 --> 14:16.620 from things like modern computing platforms and the project creates new possibilities for 14:16.620 --> 14:23.740 how desktop environments can actually be developed in the future and like tested and delivered basically 14:24.120 --> 14:31.040 to users and the kind of direct connection between software creators and users I think 14:31.040 --> 14:36.860 really strengthens both like the software quality and in the end will probably strengthen 14:37.420 --> 14:43.680 user satisfaction as well by kind of eliminating those traditional layers of modification 14:43.680 --> 14:51.760 in delay that exists as well as eliminating the politics that now infects like so many different 14:51.760 --> 14:58.000 distros in so many different ways where like they actually block improvements many of the times 14:58.000 --> 15:05.300 just they don't have the same political views as me it's moronic at best if you actually want to 15:05.300 --> 15:11.940 contribute to the development community kde will no doubt welcome contributions ranging from 15:12.780 --> 15:18.520 testing and bug reports to documentation and code development I really look forward to reading 15:18.520 --> 15:24.800 you guys's comments in this video so please let me know what you think do if you've used kde in 15:24.800 --> 15:29.900 the past feel free to mention that and in case thank you for watching at the end as always i'll see 15:29.900 --> 15:30.440 the next video