Hacker News Reader

Comment by pkulak | Hacker News Reader

I know that open source and Linux in general don't need/want another DE, but selfishly... I really want System76 to succeed. They give me the same kind of feeling I had when Apple was kicking butt in the early 2000s. And I think that for them to become a general-audience company, they need to really own more of their software. They have some great ideas, and they've already plugin'ed Gnome to within and inch of it's life; it's time to move out on their own. And it's not like a new DE means apps won't work. DEs are just the window dressing and computer management.

What I really wonder about is Wayland support. Is this going to be a brand-new DE that's X only? That would be a real shame. I know System76 has stuck doggedly to X because they sell so many NVidia cards, but NVidia supports GBM now.

View on HN

> I know that open source and Linux in general don't need/want another DE

Unpopular opinion, but more DEs is fine and good, especially if they will have teams that are either (a) large or (b) well-funded. Plasma and GNOME are very good, and Unity was actually great to use in its heyday.

Imo what we don't really need more of are the conservative, under-resourced 'classic look and feel' DEs like most of the minor players in the space. Those tend to end up incomplete and ill-performing, and there are already lots of them. I hope the existing ones thrive, but I don't think having more f them would do much good.

But anything as good as the big two, but with a different focus? Let's see it!

If this DE has low resource usage and working freedesktop screensaver protocol implementation and idleness implementation but doesn't force me on their toolbar and window manage I'll take it immediately.

Lxqt is the closest to allowing that because it wraps standard tools when possible, but this wrapping of standard tools also means that those tools don't really work.

For example, I use slock for screenlocking, but there is actually no working third party freedesktop screensaver implementation that doesn't tie you into their DE.

Xsecurelock seems to have hacks for it, but it can't even do something as simple as just showing an image without breaking with the wrong window compositor.

> more DEs is fine and good, especially if they will have teams that are either (a) large or (b) well-funded.

Or if they're interoperable. For instance, icewm doesn't have a screensaver of its own, but it just uses xscreensaver so it's fine.

A DE is pointless without the apps that run on Linux.

And that's the problem with the proliferation of DEs. Applications, which range from having no developers actively working on them, to the best teams at Microsoft working on them, have to handle yet another DE, and have to deal with the bugs raised by the users of yet another DE, etc.

UI/UX is hard enough to begin with, but requiring devs to either maintain several UI/UXs, or try and come up with a design that works across the proliferation of DEs is highly counterproductive.

> And that's the problem with the proliferation of DEs. Applications, which range from having no developers actively working on them, to the best teams at Microsoft working on them, have to handle yet another DE, and have to deal with the bugs raised by the users of yet another DE, etc.

Ideally, that's what the freedesktop.org specifications help with. You build against the specs and interfaces, and the code should work across DEs that implement specs from freedesktop.org. In my (albeit limited) experience of writing against freedesktop.org specs, it works pretty well.

> UI/UX is hard enough to begin with, but requiring devs to either maintain several UI/UXs, or try and come up with a design that works across the proliferation of DEs is highly counterproductive.

Very few developers actually attempt to do this, on any platform— virtually none, as far as I can tell. It's slightly more common on macOS for developers to actually try to emulate or reuse the design language and look-and-feel of the base system. But on every platform, it's extremely common for GUI apps to just throw the design language and other details of platforms they run on completely out the window. It's the M.O. for the most popular cross-platform toolkit right now (Electron). For every app that maintains multiple UIs, there are at least ten that do that, maybe a hundred!

Besides, COSMIC doesn't use a new graphical toolkit. It uses GTK+, just like GNOME.

A lot of developers are very concerned about UI/UX. Linux just makes it impossible for them to do so.

But even without them caring for UI/UX, the proliferation of DEs, even with common UI toolkits in the Linux world means they spend a lot of time and energy working on bugs that are not true bugs but are artifacts of a UI theme that the developer did not consider while developing their app.

For example, it's almost certain that the unified tooltip in COSMIC will lead to bugs complaining about how users are unable to drag the window by clicking on the chrome. In this case it would be fairly easy for a dev to close the bug because this is such a prominent and obvious difference in COSMIC. But there will certainly be other UI differences that will not be as easy to pin down to being the result of COSMIC's UI changes, and will not be as easy for devs to close.

This is only true if they use another toolkit. If they choose GTK or Qt it's fine.

Edit: it's GTK so no problem

Many app developers have complained that even within Gnome, apps developed using GTK get a very high number of bugs that are caused by unique customizations that the user may have installed and no one else does. These bugs, despite being significant in number, consume an even more outsized amount of resources and energy because they are very difficult to reproduce.

System76 is only adding to that mess.

"Significant in number" is a funny way of writing statistically insignificant.

I think devs can use Gtk if they're developing for Linux or don't mind using pyGtk for multi-platform, use Qt or Flutter otherwise if they're going multi-platform, make sure everything follows freedesktop specifications, and then just pack it to Flatpak, test it for Gnome and KDE... then just tell everyone whose DE doesn't support it to just deal with it.

Heck, many apps are web-based and uses electron anyways, and those are generally multiplatform anyways.

I think if whatever app they make/port worrks via Flatpak, it should work on all/most modern distro.

Yeah a new DE would be welcome. I hope this will be less opinionated and barebones than gnome. That just needs too many add-ons to be useful.

I use KDE now which does provide a lot of choice but I'd love something that has tiling built in. And yeah I know there's add-ons for KDE that do that :)

Any recommendations for good tiling managers for KDE?

There is krohnkite but I recently read development was halted and there was a new more favourable one. I've bookmarked it somewhere but I'll check!

Edit: this is the one: https://github.com/Bismuth-Forge/bismuth

There's also kwin-tiling https://github.com/kwin-scripts/kwin-tiling

Not sure which is best tbh. I have yet to try them

You can also use i3wm as tiling window manager. It replaces KDE‘s default window manager. I had good experiences with that.

Guide: https://userbase.kde.org/Tutorials/Using_Other_Window_Manage...

True but you lose a lot of integration that is really nice to have. This why I never chose this option even though I use i3 on more barebones systems.

>more DEs is fine and good

I tend to disagree here. I recently switched back to MacOS after years of running both. The DEs on Linux are just one generation behind. Things have gotten better, but macOS and to an extend Windows are ahead.

Linux DEs would be well advised to onboard more graphics and UI experts to make them more user-friendly and stable. Desktop metaphors have more or less stabilized and it's counter-productive to have 5 takes on the Linux-side alone.

> user-friendly

The entire problem starts and ends with this term. It is ambiguous, personal, localized, fluid and case-dependent.

What is friendly to one user, is insulting to another. What is friendly to me at 10:00 in the morning is frustrating when I have a presentation in two minutes. What is friendly to an American pensioned welder, is insulting to an Iranian accountant.

It's interesting how people want so different things. I can't stand windows for 5 minutes before it's user interface starts to really annoy me. And mac looks great but all the Linux technology underneath is from the Stone Age.

Just to explain why I love Linux so much - when I'm in Gnome, I'm not bothered by any alerts or notifications or popups or sounds or ads or anything! It's a silent, stable, good looking desktop that runs my programs and doesn't get in my way at all. It's amazing! I truly love it.

If the majority of companies that rely on Linux use it as a server for some kind of service(s), desktop environments or even graphics are not a priority. That's not to say that such use-cases don't exist. But the focus is, generally, not on outshining another OS or platform through the user interface or graphics.

I don't disagree, which is why I use KDE, as it is trivial to get it to look and behave like macOS and do so stably. Probably why many KDE distro that aren't following KDE's defaults use it too (Garuda Linux, XeroLinux, FerenOS)

I think Linux DEs are fine, it's just that the default config / on-boarding rarely asks what the user wants and what they need.

More distro/DEs need to incorporate UX/Desktop Layout Switcher, like Ubuntu Budgie, Zorin OS (Gnome, XFCE), Manjaro (Gnome, there are plans to do KDE as well in the forum?), and FerenOS. It'll solve the issues of personal preference in UX, as people could just one-click choose what feels/looks the best for them.

I personally don't mind taking a few hours setting up the UX I want with Fedora KDE, but I doubt most others do.

The shell is implemented in GTK4, and the compositor depends on smithay[1], so I assume they plan for Wayland support.

1: https://github.com/pop-os/cosmic-comp/blob/main/Cargo.toml#L...

Interesting, thanks. Guess they went that way because of Rust, but it would have been super cool to have another wlroots compositor on the block.

EDIT: Just found this, which explains a bit: http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i...

You never know what's possible in the future but I imagine right now they're working on the core features so supporting every compositor around is down the road a bit.

DEs are just the window dressing and computer management.

That's how you end up in a situation where the contents of the window clash with the dressing because more and more apps can't be themed. If they want a consistent look they'll need to fork or write a whole new set of apps.

The irony is that the reason why authors claim when they remove theming is to have a consistent look.

For some apps I don't care too much, because I run them in full screen anyway, and their specific look is adjusted to their function: IDEs, DAWs, even graphic editors. But if they do support DE-wide themes, I do appreciate that!

Yeah, GNOME should just admit that it's an OS and stop pretending to be a framework or DE or whatever.

They sort of do. https://os.gnome.org/

Consistent look?

If you’re thinking of the website I’m thinking of [1], the screenshot they lead with isn’t just inconsistent. It’s broken, with light text on a white background. And I’ve seen apps fail in that same way for real when trying custom GTK themes.

It’s the same reason web browsers can’t change the system CSS stylesheet without extreme measures like Reader Mode that strip almost all of the design work out of the site: it’s hard to mix design work from two different people (the application author and the theme author) without risking a total mess.

[1]: https://stopthemingmy.app/

Not only that, you also end up with half baked applications because there isn't a consistent development stack so applications are stuck with UNIX IPC for communication about themselves.

GNU/Linux apps will never have something like OLE 2.0 or XPC that actually works consistenly across desktops.

There is D-BUS, but not everyone cares it is there.

As a Linux newbie I'm wary of distributions that include many of their own custom apps. I know most of these teams are just a few people and I doubt in their ability to create the "Apple" (OS + Apps) experience. Alas, I'm new to this so perhaps I'm missing something.

Do any Linux experts out there feel the same way?

I don't mind system76 succeeding, that would be great, but I have not really liked any of their laptop offerings. I also really don't want another half funded DE for Linux. I really wish they would dedicate these resources to improving GNOME and gtk instead. Things like VRR, DPI scaling, touchpad behaviour, prioritising wifi driver bugs, basic things like copy/paste interactions between apps, screen sharing et.al. are still less than great experiences on Linux and is more important to improve than a new half baked UI.

If what we want is a rewrite of GNOME with COSMIC features, that's not going to happen with GNOME. We already submit patches to GTK, and GTK4 is gaining layer-shell protocol support as a result.

Screen sharing is already made easy with Pipewire. I've not seen any issues with copy/paste between applications. WiFi driver issues can only be fixed by kernel driver developers with hardware documentation for the exact model of the PCI device they're writing a driver for. The same goes for touchpad drivers, but I've not had any issues with them on our laptops. We sell systems where we can vouch for the quality of the driver support in Linux for the WiFi and touchpad.

In my opinion, you're wasting your time with layer shell. The design of it is very X11-like and flawed. Panels setting their own position is problematic and prevents the shell from doing layout updates in one pass. You'll want to drop it eventually and use a private shell similar to the way it's done in weston.

It seems to use wayland: https://github.com/pop-os/cosmic-comp/blob/main/src/main.rs#....

Yet it also seems to be using an "x11 backend" (only) for now... not sure what to make of this without reading the code a lot closer.

https://github.com/pop-os/cosmic-comp/blob/main/src/backend/...

It is Wayland only, and the X11 backend is for running applications in a nested X11 client.

I left PopOS and never looked back when I needed nvidia-docker to do some deep learning work and learned they had knowingly made it difficult to impossible to reliably use nvidia-docker with PopOS, and they recommended their own unmaintained project that doesn’t even intend to be a replacement for nvidia-docker. It couldn’t have been more useless to me.

Breaking compatibility with Ubuntu-compatible dev tools is one thing, but the lack of awareness or consideration of tooling standards is evidence that Pop_OS! is not for me.

They occasionally have driver mismaatches between the upstream containers and the distro-provided driver. This happens because nVIDIA only supports Ubuntu LTS releases and Pop moves faster. I solved it forever by pinning nvidia's repos to a higher priority. Otherwise I can't figure out what "unmaintained project" you're talking about, or what "tooling standards" are.

They are most likely referring to `tensorman` https://support.system76.com/articles/tensorman/ which is regrettably premised on the notion that you have any intention of using Tensorflow in the first place.

Unfortunately, the `tensorman` article shows up first (after several complaint/support threads) in a google search result for the subject https://www.google.com/search?hl=en&q=nvidia%20docker%20pop%...

In all actuality, the correct article to reference is https://support.system76.com/articles/cuda/ but alas, this is presently broken on PopOS 21.04 unless you pin nvidia's repo's as you've suggested.

At the very least, an unpleasant experience. Probably some blame to be shared by system76 and nvidia.

It wouldn’t be a significant if the Pop OS developers weren’t telling users that they don’t need nvidia-docker. Of course, they can tell users whatever they want, but I’m not going to trust their OS if this is how they plan to handle things like this.

Since when have we told anyone that they don't need nvidia docker packages installed? You can validate that the Debian packaging has always shown nvidia-container-runtime/nvidia-docker as a recommends for CUDA support.

I am actually participating in a thread right now where contributors are happily trying to solve this issue. Their devs are very helpful if you reach out.

https://github.com/pop-os/pop/issues/1708

`sudo apt install nvidia-docker2` works on 21.10. I have been packaging NVIDIA's container toolkit since tensorman was created, because tensorman doesn't work without nvidia's container toolkit. It's a dependency.

Nvidia-docker is not the same as nvidia-container-toolkit, and neither of them have official support for 21.10 the last time I checked (a few months ago).

It is a component of nvidia-container-toolkit. Take one minute to browse the Pop repository and you'll find three packaging repositories forked from NVIDIA. libnvidia-container, nvidia-container-toolkit, and nvidia-docker. Installing nvidia-docker installs support for the whole system. Now you have functioning NVIDIA support in containers.

You mean the one that you forked 12 days ago? What are you trying to accomplish by acting like it has been packaged all along?

https://github.com/pop-os/nvidia-docker/commit/aa9fbcff6e6e5...

This changes nothing about my story of the Pop OS developers previously thinking it could be replaced with their bespoke custom tooling.

This is a new repository that replaces a pre-existing nvidia-container-runtime repository that we've been using since 20.04 that does the same thing. It still remains that tensorman would not function without NVIDIA docker container support, because it's literally just a convenient frontend for interacting with Docker's CLI.

I never said otherwise. As you know, nvidia-containter-toolkit only very recently merged with nvidia-docker, and you know perfectly well that you have not always packaged or supported nvidia-docker.

Blame NVIDIA instead. If they had open source their blobs, it would have been everywhere out of the box. Most evil company for open source ever.

>Most evil company for open source ever.

I won't ever defend nvidia, but... I really think Broadcom is worse. They've ruined tons of routers and wireless cards. Also, the Raspberry Pi is full of blobs because of them.

Raspberry Pi seems to be doing just fine with them, whereas the FOOS competition is where exactly?

Allwinner, Rockchip and Mediatek seem do be doing just fine without all the blobs.

So where are their Raspberry Pi like boards being adopted like crazy by the Maker community?

I’m not looking to blame anybody. System76’s approach just conflicts with my priorities when choosing an Ubuntu-based distro. I prefer to not have my OS surprise me with requirements that I replace a major portable dev tool standard with one of their bespoke unmaintained side projects. I doubt I am alone and maybe others will find the info useful. I just can’t trust their work any longer after realizing they were serious about that tool of theirs being a replacement.

Hollywood and HPC are don't seem to care about it.

Can you expand on what in your view System76 did to impede it?

I’m sorry, I don’t quite recall the details but it was a few different things. The main one is forcing certain Nvidia libraries in the package manager so you need to take a few steps to undo some of the Pop OS Nvidia installation, which breaks other Pop OS stuff, of course.

There is no need to undo anything. We regularly test CUDA functionality with our packaging, and it's the whole point of having the packaging in the first place. So you don't have to manually install things from a third party repository or deb.

“CUDA functionality” and nvidia-docker are not the same thing and you know it. This is the attitude that has me turned off off. Just acknowledge and we could move on! Unless you deleted them, anyone can search your github to find your comments telling users to use your bespoke tensorman tool instead of installing nvidia-docker, acting like one is a replacement for the other. And with the same presumptive attitude.

I have no idea why you're trying to argue with me over absolutely nothing. You could have saved so much time by asking questions instead of accusing me of things I haven't done, and spreading misinformation about it.

CUDA support in Docker requires nvidia-docker+nvidia-container-toolkit+libnvidia-container, and that is the whole point of having nvidia-docker installed. We validate that CUDA functions inside of Docker when pushing updates to nvidia-container-toolkit and friends.

Tensorman is not a replacement for nvidia-docker, and you're not going to get anywhere by trying to convince me about the functionality of something that I personally wrote. It is quite literally just a simple command-runner that runs docker commands, specifically for the purpose of managing the official Tensorflow Docker images, and getting a more streamlined setup for managing your local Docker images based on them. The sole purpose is to replace our previous tensorflow packaging in Pop!_OS that became impossible to package because newer versions of Tensorflow did not build beyond 18.04. Tensorflow themselves recommend using their docker images instead of trying to package and install their libraries on your host OS.

OK here is a question: Why do you tell people to use tensorman instead of nvidia-docker when they have problems with nvidia-docker?

I agree there's an old-school Apple feel to it. The difference may be that System76 is concerned with user freedom: from coreboot to COSMOS they intend to produce and support FLOSS.

I think if Apple had embraced free software early in its history, it could have known a much brighter future (err, present?). Hell, even HyperCard may still be alive and kicking.

I developed software for Mac OS X around 2005 and I can guarantee you that Apple certainly wasn't kicking butt back then and is probably even worse off today with OS X becoming bloated and full of cruft.

> I really want System76 to succeed

Succeed at what ? Re-implementing Gnome in Rust ?

Selling lots of Linux-based hardware that they design in-house.

> Re-implementing Gnome in Rust

That seems a bit disingenuous. It's all still GTK.

gnome =! gtk

sure they are a bit more related then KDE and QT, still but the same at all

We all know that. I assure you. Gnome uses GTK and evidently Cosmic 2.0 will use GTK

GNOME uses Mutter+GJS, which is quite a bit different from GTK. But sure, GNOME applications are written in GTK.

Sure, but there are already a number of different desktops hurting for maintainers. There is a lot hardware that doesn't work great with my os (which might be a BSD) and I want them to fix that.

> lots of Linux-based hardware that they design in-house.

Are their Clevo-based laptops designed in-house? If they are, why are they designed with such abysmal speakers, mediocre webcam and no attempt to go past the full-HD screen resolution? Why not design something cool like Framework?

Nope, I don't consider those in-house. They are working on an in-house laptop, and if it ends up anything like their in-house desktops, it could be really nice.

Do you have a source for that?

This would really be a game changer. Unfortunately, you need a really great number of units, that building your own custom laptop hardware is feasible. I really which System76 success with that.

I always thought, if Dell were smart, they would do their own Linux-based brand, where they would reuse parts from mainline Dell. Kind of how they produce gaming laptops.

In November 2019, System76 announced that it would start designing and developing laptops in-house starting January 2020. The development process was estimated to take 2-3 years. The first generation of System76’s in-house desktop line (Thelio) took over 2 years to develop.

- Article: https://www.forbes.com/sites/jasonevangelho/2019/11/20/syste...

- HN: https://news.ycombinator.com/item?id=21586422

If you have any suggestions for the laptop design, System76 is collecting feedback here:

https://github.com/system76/laptop-suggestions

Thx.

I think you can assume they meant succeed at creating computers people love to use and selling them.

Hopefully not.

Not re-implementing Gnome. Not re-implementing macOS which Gnome strives to imitate. OTOH I see the value of that: many people got used to macOS, and making things similar, and the cognitive load of switching low, makes business sense. Same as with Windows in early 2000s.

HackerNews is really a bubble sometimes. I don't get who the "many people" that "got used to macOS" are.

Apple had fiery fest of sales in Q4 2021, outsold all Wintel manufacturers, let alone Chromebooks. And after that, guess what, they now have 8% of desktop/laptop market share, instead of 6% they used to have. You can guess who covers most of the other 90+ percent.

Sent from my 2021 M1 Max MBP.

At making 2022 the year of Linux in the Desktop!

They're one of the few players selling modern coreboot machines

I have seen this comment a few times but basically half the desktop environments for Linux are GTK. So, using GTK does not equal “re-implementing Gnome”.

I use Cinnamon with Manjaro - it is not GNOME but it is GTK. Unity was the same. MATE is old GNOME but quite different from new GNOME — still GTK though. XFCE, LXDE, and pretty much every popular DE outside KDE and FVWM2 is based on GTK.

Choosing Rust has nothing to do with re-implementing GNOME either although I do like that choice. If nothing else, this ensures well tested Rust bindings and paves the way for devs to write other GTK apps in Rust—-perhaps even ones intended to target GNOME itself.

cinnamon uses enough gnome libraries to count as using re implementing gnome

Reply on news.ycombinator.com