-
Notifications
You must be signed in to change notification settings - Fork 7
Katana, is a fork of K Desktop Environment (KDE) with emphasis on efficiency. So far it has proven to be roughly 50% less system resource hungry and significantly faster.
Since most of the focus is towards KDE Frameworks (KDE5) now and there is little going on on the KDE4 side we decided that it would be a good time to start cleaning up the project, cut the fat and make it more usable on not so powerful systems. Having said that there are a lot of changes done so far which remove as little functionality as possible for the benefit of better overall performance. Most of the changes are internal and it is unlikely that you would miss what we undid.
KDE developing practices are good but they tend not to break compatibility which means that the existing code can not always take advantage of all the goodies the modern software ecosystem offers. For an example, LibArchive supports variaty of compression formats and is used on some sub-projects (Ark) but not in the core (kdelibs) which means duplication of code (read time and money) for something that can be achieved far easier and less painful. But for this to happen APIs and ABIs must be broken - KTar, KZip and friends can be removed and KArchive taking advantage of LibArchive would be the way to go.
But that rises another question - why not take advantage of Qt5 and contribute to KDE5 instead. Well, KDE4 fits pretty well for use on existing systems and it will take quite some time before KDE5 gets as mature as KDE4, meanwhile we shall keep and maintain the best of KDE4.
First, you must understand how forking a big project works. There is a lot of rebranding involved and to keep this to the minimum the name "Katana" was chosen thus we do not have to change every reference to "KDE". As you already may have guessed it you can refer to Katana as Katana Desktop Environment.
Good question. An incomplete list of changes done can be found on this page, it includes the changes done to certain point in time. After that the project has undergone many user-visible and under the hood changes. Overall - the project is not about being just KDE anymore, it is about going forward from where its development stopped.
Altought there may be some areas to improve, most bugs had their bubble gum kicked out and we continue to hunt the rest. Report issues if you stumble upon one. Have in mind that any issue may not lay in Katana, it may be in library, application or compiler it uses. In other words, it is mostly feature complete and there should be no major headaches. There are even features that only Katana can offer.
There isn't really. Releases are issued when several major improvements have been made, enough testing is done and so on. Mostly minor releases are made (e.g. 4.18.0) not micro/patch releases. Important patches are published for the latest release as an update, if you are packaging Katana for a distribution we recommend watching the repository to get notifed when they are added as part of a release. If that does not fit your personal preferences you can always pull the latest source and build it yourself, you will be surprised how easy it can be and you may learn a thing or two in the process.
There are no plans to make LTS releases, the project in its current state is pretty stable and if there is an issue it is most likely inherited design issue or feature is not finished yet.
First of all, it does not support Windows and Mac as KDE does with BSD being partially supported (some functionality has not been tested yet and it's not very easy due to the inability to dual-boot BSD (newfs refusing to create filesystem on non-BSD partition layout, read-write UFS filesystem not being enabled for Linux kernels, mouse and keyboard freaking out in VMs, etc.). The goal is to support some UNIX-like Operating Systems, such as Linux and the BSD family. In terms of source compatibility most KDE applications should work with Katana after minor adjustments but anything not shipped as part of our releases you should use at your own considerations. Source compatibility between releases is not guaranteed but the aim is to retain most of it, we do not guarantee binary compatibility and encourage full rebuild when a new release is made.
ext4 filesystem can choke your hard-drive if changes are commited too often and with barrier which is not a problem in Katana itself. You can however reduce the reads by opting out of the metadata plugins, there are options for them in the system settings. Also, bare in mind that plasmoids (desktop and tray applets) mostly use declarative interface and they are quite resource consuming.
If the behaviour is observed from a Live CD/DVD/USB image that is because Plasma used to (but not in 4.19.0 and newer) store rendering caches to disk in addition to RAM. This makes the cache use twice as much as it should in such environments because they use temporary storage (tmpfs/aufs/overlayfs) that uses the system RAM instead of an actual disk (USB/HDD). The biggest caches were two of ~80MB each and they used to be stored as /var/tmp/kdecache-<username>/*.kcache (usually). That means that ~160MB were wasted immediately after KDE was started in such environment.
Yes, you can. There are various task you can help. For an example, for translating the sub-projects you will have to work directory with the .po files. Just fork, make changes and pull requests.
Implement it yourself, pay someone else to do it or just deal with it. Some changes such as Wayland support (which years after its adoption by some other projects is still far from complete) will never be accepted as that will limit the functionality Katana provides in the short term and in the long term there isn't even need for such due to XWayland. Katana makes use of many other open source project which you have to get to know and consider improving those first. As an example if Ark does not have support for some archive type which can be implemented in libarchive then there is no need to make a CLI plugin for it and the changes to Ark itself will be minimal.
See the contributors page. And feel free to join us.
Contact one of the contributors, see above.