The Linux kernel already allows proprietary modules via DKMS, and a handful of vendors have been using this for decades, so this is no different. Case in point: NVIDIA driver, and Android vendor drivers.
All source code in Rust is statically-linked when compiled, which thereby renders the LGPL no different from the GPL in practice. For Rust, the MPL-2.0 is a better license because it does not have the linking restriction.
All desktops use the Super key nowadays. Sway, i3, GNOME, Plasma, etc. are all using the Super key. Have been for years. The standard convention is that the Super key is reserved for system-level shortcuts handled by the window manager; and Alt key shortcuts are reserved for application-level shortcuts. Your desktop might have bound both Alt and Super because of legacy reasons.
It will be possible to configure COSMIC to look like Unity out of the box. There's only a few panel applets that need to be implemented to make the experience 1:1.
cross-posted from: https://lemmy.world/post/13038090
https://fosstodon.org/@soller/112083947500126938
COSMIC Store is coming along quickly, though there is still a lot left to do. It loads nearly instantly, because it uses bitcode to cache appstream data in an optimized format. It uses very little memory compared to the Pop Shop. Searches can be performed live as they are done in parallel. Searching for "e" takes 5.5 ms on my desktop and returns 4601 results.
Because that's not how software development works, and that's not how you make progress in the field. In order for our technical vision to be integrated with an existing desktop, such as GNOME, it would have required that they give us the reigns to their project to delete their entire codebase and rebuild it into exactly what you see today in COSMIC.
As in life, sometimes you've got to demolish, pave, and build better foundations. There's a lot of cool technologies available to build a truly next-generation desktop experience in, but you're not going to get it through rigid bureaucracy and old tools. With COSMIC, we've got freedom to make decisions and build something truly unique, and we're using our talent to show you what we can do.
No, we have been making our own platform toolkit (libcosmic), which is built upon iced-rs. We are using this both for our wayland compositor applets, and our desktop applications.
I am still actively maintaining Pop!_OS. COSMIC has not changed that aspect of my job. Just within the last week I packaged Linux 6.6.8, Mesa 23.3.2, Just 1.22, Rust 1.75.0, and updated Popsicle's dependencies to fix a bindgen build error with recent versions of Clang. We have a systemd update that was packaged today, and I'll be doing another linux-firmware backport soon. So I don't understand why you'd think it is stagnant. We're even shipping Pipewire 1.0.0 by default, which Ubuntu hasn't yet done in the latest version. People usually complain that we update too often.
2022 was only a year and a half ago, and we ship the latest Linux kernel, firmware, Mesa libraries, NVIDIA drivers and libraries, Pipewire/Wireplumber, ZFS, Firefox, Alacritty, Lutris, Steam, and Rust. Since when did we start considering that to be "incredibly ancient"? The next LTS release is not yet available to base Pop!_OS upon, but we ship newer kernels and drivers than the latest version of Ubuntu.
As is often the case with scientific research which many people believe to be pointless, technological innovations aren't always made by achieving the end goal, but through the technologies developed to reach that goal.
Development on COSMIC Edit has lead towards improvements to the cosmic-text library, which is used by many GUI libraries in the Rust ecosystem now. Similarly, the UX designs for the text editor improves the COSMIC interface guidelines, and puts design theories to practice. Likewise, widgets that are necessary for the editor are added to the COSMIC platform toolkit, and existing widgets and features are improved to improve the development experience for applications like this.
No one would want to build applications for a platform that lacks widgets capable of properly displaying, formatting, and editing text. Many would also find it debilitating to have a desktop environment without a text editor preinstalled. Imagine if GNOME didn't have Gedit, and KDE didn't have Kate.
Besides, this is a default text editor for a desktop environment. It is really not that complex. The goal is not to develop an IDE, but a text editor that anyone would feel comfortable using as their default editor on the COSMIC platform.
GNOME was focusing on building Rust bindings for GTK for many years before Qt development picked up. The GTK bindings were usable within a year or two after Rust's 1.0 release. Yet even today, those looking to build applications in Rust will find that GTK is the only mature toolkit right now. And if you're doing that today, I'd recommend starting with Relm4 for the best GTK Rust experience.
Rust does not support the C++ ABI, and Qt does not provide a C interface, so much work has to be done on building the tooling for binding C++ libraries to Rust. That work is still ongoing, so some have opted to use QML instead of interfacing with Qt C++ libraries. Yet if you're looking to use Qt or QML, you may as well use Slint instead. It's developed by former Qt/Trolltech developers and has a similar approach as QML.
This year? No. We are still working on achieving our Alpha 1 milestone.
It's not as simple as you think it is. First, we use Plausible instead instead of Google Analytics, so tracking data is not being given to Google. If the choice was purely up to System76's web team, use of Google services wouldn't be required. However, you'll be hard pressed to find any online store that accepts online payments without a captcha service, because most payment processors require it. System76's payment processor also requires it, and will not allow you to substitute your own solution or bypass that requirement. Same as said here: https://lemmy.world/comment/3137069
Customer services and other web-facing frontends are also a constant target of attacks, so a captcha service is required.
In practice, because Rust libraries are always statically-linked, the MPL-2.0 is equivalent to the LGPL in spirit. Meanwhile, because of the static linking restrictions in the LGPL, the LGPL is effectively no different from the GPL. Hence, you're going to find a lot of open source copyleft projects from the Rust ecosystem preferring either GPL or MPL-2.0, where MPL-2.0 is used in libraries where LGPL would have used previously in C projects. Dynamic linking is essentially going the way of the Dodo.