Vanilla is a complex and delicious flavour



If we’re looking at the code shipping in Endless OS today, then yes, our desktop is vanilla GNOME Shell with a few hundred patches on top, and yes, as a result, rebasing onto new GNOME releases is a lot of work. But the starting point for Endless OS was not “what’s wrong with GNOME?” but “what would the ideal desktop look like for a new category of users?”.
When Endless began, the goal was to create a new desktop computing product, targeting new computer users in communities which were under-served by existing platforms and products. The company conducted extensive field research, and designed a desktop user interface for those users. Prototypes were made using various different components, including Openbox, but ultimately the decision was made to base the desktop on GNOME, because GNOME provided a collection of components closest to the desired user experience. The key point here is that basing the Endless desktop on GNOME was an implementation detail, made because the GNOME stack is a robust, feature-rich and flexible base for a desktop.
Over time, the strategy shifted away from being based solely around first-party hardware, towards distributing our software a broader set of users using standard desktop and laptop hardware. Around the same time, Endless made the switch from first- and third-party apps packaged as a combination of Debian packages and an in-house system towards using Flatpak for apps, and contributed towards the establishment of Flathub. Part of the motivation for this switch was to get Endless out of the business of packaging other people’s applications, and instead to enable app developers to directly target desktop Linux distributions including, but not limited to, Endless OS.
A side-effect of this change is that our user experience has become somewhat less consistent because we have chosen not to theme apps distributed through Flathub, with the exception of minimize/maximize window controls and a different UI font; and, of course, Flathub offers apps built with many different toolkits. This is still a net positive: our users have access to many more applications than they would have done if we had continued distributing everything ourselves.
-
- Login or register to post comments
Printer-friendly version
- 2123 reads
PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
today's howtos
| Wine Developers Are Working On A New Linux Kernel Sync API To Succeed ESYNC/FSYNC
While there is the prior "ESYNC" and "FSYNC" work pursued by Wine for the Linux kernel, it appears Wine developers are back to the drawing board in coming up with a Linux kernel implementation for Wine synchronization primitives that will address all their needs and match the Windows behavior well.
CodeWeavers developer Zebediah Figura sent out a lengthy mailing list post on Sunday night outlining the current state and objectives of coming up with kernel-based Wine synchronization primitives. While the ESYNC/FSYNC patches were successful in improving the performance of many Windows games running on Linux, they are still working towards a more all encompassing solution and to match the behavior well for Windows and with optimal speed.
|
Linux Weekly Roundup: Wine 6.0, Fedora i3 Spin, and More
Here’s this week’s (ending Jan 17, 2021) roundup series, curated for you from the Linux and the open-source world on application updates, new releases, distribution updates, major news, and upcoming highlights. Have a look.
| Linux 5.11-rc4
Things continue to look fairly normal for this release: 5.11-rc4 is solidly average in size, and nothing particularly scary stands out. In the diff itself, the new ampere modesetting support shows up fairly clearly - it's one of those hardware enablement things that should be entirely invisible to people who don't have that hardware, but it does end up being about a fifth of the whole rc4 patch. If you ignore that oddity, the rest looks pretty normal, with random patches all over, and a lot of it being quite small. All the usual suspects: drivers (gpu, sound, rdma, md, networking..) arch updates (arm64, risc-v, x86), fiesystems (ext4, nfs, btrfs), core networking, documentation and tooling. And just random fixes. The appended shortlog gives the details as usual.. Linus ![]() |
Recent comments
1 hour 7 min ago
1 hour 33 min ago
1 hour 35 min ago
6 hours 5 min ago
6 hours 8 min ago
12 hours 31 min ago
12 hours 42 min ago
1 day 10 min ago
1 day 1 hour ago
1 day 7 hours ago