@mmstick@lemmy.world
@mmstick@lemmy.world avatar

mmstick

@mmstick@lemmy.world

I’m a System76 engineer / Pop!_OS maintainer. I’ve been a Linux user since 2007; and Rust since 2015. I’m currently working on COSMIC-related projects.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

mmstick, (edited )
@mmstick@lemmy.world avatar

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.

mmstick, (edited )
@mmstick@lemmy.world avatar

There are new versions released every two or three weeks. I’m about to release Linux 6.6.8 with Mesa 23.3.2. We have Pipewire 1.0.0 and NVIDIA 545. ISOs are regularly rebuilt with our latest updates.

mmstick,
@mmstick@lemmy.world avatar

Pop!_OS has released 37 versions based on Ubuntu Jammy, though. Soon to be 38.

mmstick, (edited )
@mmstick@lemmy.world avatar

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.

mmstick, (edited )
@mmstick@lemmy.world avatar

It’s not stable in the Debian sense. We’ve always had rolling release updates for the system base; and people often complain about regressions in Linux, Pipewire, Mesa, and NVIDIA updates. I get them packaged shortly after they’re released. As long as they pass QA tests in the System76 hardware lab, they get released within a week.

mmstick, (edited )
@mmstick@lemmy.world avatar

I’m defining it the same way that Mint and Ubuntu is here. Which is when they release a new version of their ISO. We are currently on 22.04.37. Release date January of 2024. There are substantial changes since the first ISO build of 22.04

mmstick, (edited )
@mmstick@lemmy.world avatar

You are misunderstanding the data. It is not the number of users, but a percent of posts to ProtonDB, which only applies to PC gamers. There can be a disproportionately larger number of reports from those who need to spend time tweaking their system as opposed to using it, or that are particularly vocal about sharing their tweaks.

The total number of users playing games on Linux is rising each year. Pop!_OS was the first OS that a lot of people tried a few years ago, and so you’ll see a lot more diversity in choice now. People who are new to Linux, yet particularly heavily invested in it, tend to like to try out a lot of different distributions in the following years.

mmstick, (edited )
@mmstick@lemmy.world avatar

They commented on their video that it was their fault. There was never a packaging issue. The issue was that we pushed a systemd source package update to Launchpad, which silently didn’t build or publish the 32-bit systemd library packages, because Ubuntu had systemd on a blacklist for 32-bit package builds. We noticed this minutes after packages were published, and had it fixed within an hour later.

This didn’t actually affect any systems in the wild because apt held back the update until we had worked around the restriction on Launchpad (there was an invisible ceiling to the package version number). They were only affected during that time period because they manually entered that sentence from the prompt in a terminal. We stopped using Launchpad with 21.10, so all packages released since then are the same packages that are built and tested by our packaging server, and used by our QA team internally.

The drama and reputational damage that LTT caused was unnecessary. Especially given that they uploaded this video a week later, and never attempted to reach out. They still have yet to properly edit the video.

mmstick,
@mmstick@lemmy.world avatar

This is already in progress. COSMIC applications are compatible with Redox OS.

mmstick, (edited )
@mmstick@lemmy.world avatar

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.

mmstick, (edited )
@mmstick@lemmy.world avatar

You are heavily overestimating how much effort is required to develop a text editor. It’s a single person project using components that had to be developed for use in multiple applications; regardless of whether there is a text editor or not. Components that you’d be silly not to develop through a text editor project.

You are trying too hard to justify that we not make a text editor. It feels like you don’t want us to make a text editor at all. No one is on a path to burnout. Everyone is paid a full time salary to work on their respective areas. COSMIC development is doing really well.

mmstick,
@mmstick@lemmy.world avatar

GNOME users wouldn’t be happy having to install KDE dependencies to use a KDE text editor which doesn’t have a consistent look and feel on their desktop. Same applies for KDE users.

mmstick, (edited )
@mmstick@lemmy.world avatar

COSMIC Edit is being developed by our manager through personal motivation; who also developed cosmic-text, so this is the perfect playground for simultaneously advanced cosmic-text, and developing useful real world software with it. The git diff view was not yet part of planned designs, but it took only a portion of a day to implement. It adds a useful test case for the cosmic-text library, and improved cosmic-text as a result.

We’re all paid a full time salary to work on COSMIC and Pop!_OS. Each person on the team is going to spend a full day writing software, regardless of what they’re working on, so concerns about burnout are somewhat silly. Burnout is typically caused by working overtime for extended periods of time. System76 has never required developers to work overtime to meet a deadline, and variety of workload can alleviate mental fatigue, so burnout is not a thing here.

mmstick, (edited )
@mmstick@lemmy.world avatar

In my experience, that has never been an issue with any Rust-based projects. It’s quite the opposite. 80% of time is spent completing the first 20% of the project, and then the remaining 80% is quickly finished as everything fits into place. Most of our time is spent in foundational work getting widgets created that we can use with our theme system, and then the actual implementation of the interface in the application is stupid easy.

What you describe is what I felt developing the GNOME extensions. There’s very little you can do to resolve issues that you encounter there.

mmstick,
@mmstick@lemmy.world avatar

You can start with the libcosmic repository, and the examples contained within. We’re going to work on revamping our design demo application soon, which will be a learning resource for COSMIC application development

mmstick, (edited )
@mmstick@lemmy.world avatar

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.

mmstick, (edited )
@mmstick@lemmy.world avatar

Yes, the libcosmic toolkit automates a decent chunk of the process to building an application with our interface guidelines. If building an application with the cosmic::Application trait. Which includes the header bar, navigation bar, and context drawer.

mmstick,
@mmstick@lemmy.world avatar

Yes, this can already be seen when configuring a personal theme in the Desktop > Appearances page in COSMIC Settings. Compositor elements, applets, the login and lock screens, and COSMIC applications automatically adjust in realtime to the configuration changes.

mmstick, (edited )
@mmstick@lemmy.world avatar

You’re so silly. If the developer doesn’t want a themeable application, then either don’t use a themeable toolkit, or hardcode the theme so that the system theme is ignored.

mmstick, (edited )
@mmstick@lemmy.world avatar

You don’t seem to realize that this is equivalent to that. The user already made the choice to install a desktop environment which generates themes. So if you make the choice to build an application with GTK, and you want users to be able to use system themes with it, then consider it done.

To argue otherwise would make you a hypocrite. It would mean that you don’t actually want users to use themes, so you take issue with desktop environments which make it easy to do so by default. So if you want people to be able to use themes, then you shouldn’t complain when people choose to use a desktop which enables that use case.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • localhost
  • All magazines
  • Loading…
    Loading the web debug toolbar…
    Attempt #