/tech/ - Technology

You WON'T fix. #notabug

>Wayland
>btrfs
What's the problem?

Why does Linux keep getting shittier? How did we go from too much fragmentation to GNOME abusing their hegemony to force their shitty ideas down our throats?

>GNOME
but im not using gnome :(

>>8539
Doesn't matter, they impose their "philosophy" on everything else they develop.

>>8538
Embrace expand extinguish, corporations were doing for a long time. It's a surprise that it held out as long as it did.

>>8538
>Why does Linux keep getting shittier?
Is it getting shittier ?
How is it getting shittier ?

Yes.

>>8538
It’s getting better. Guix is the best linux distro to date

How do I get all my files from Windows onto Debian? I have Debian on my laptop and I love it, but my desktop computer is so integrated with Windows that it'd be a massive pain in the ass to switch OS's. Should I just cop an external hard drive and put all my files in there?

>>8562
XFCE is just as bad. Just use LxQt, LXDE, or
Mate if you’re not going tiling. Full IDEs will just bog down your system.

>>8565
That’s what I would do if I were you.

>>8566
Ignorant take. Xfce has the same memory footprint as MATE while it does a lot more things.

>>8561
What's so great about it besides the fact that its leaders are libelous wreckers trying to destroy the GNU Project?

>>8569
simple configuration
simple package manager
simple package definitions

>>8562
XFCE uses GTK3, so GNOME decs are sneaking their shit into your xfeces

>>8574 (me)
*devs

Pipewire is the best option yet
GTK is fine for the most part, it's not constantly risking oblivion like QT is
BTRFS is fine outside of one configuration

>>8576
>Pipewire is the best option yet
The best option for what? Most of the time with projects like these it's something most users don't need. So for us it only has bad side-effects and more vulnerabilities without any gain.

>>8574
This is why you should upgrade to a tiling window manager.

>>8578
What do you think of minimal floating WMs like rio and cwm?

I used i3 and then dwm for a while, but noticed that I switched between the virtual desktops most of the time, and when I briefly used cwm on a fresh OpenBSD install, I found I could organize windows more efficiently when they overlapped.
Now I use rio, because it fully exploits the mouse.

>>8577
> Most of the time with projects like these it's something most users don't need
that’s literally what Pulseaudio was, and now we’re coming full circle. All of Linux’s problems are internal. It will never be the year of the linux desktop until the programming community as a whole gets its shit together.

>>8577
The Linux audio ecosystem is a mess as it stands today.
There are three different audio layers: ALSA which can control audio for only a single application, PulseAudio which is buggy and a pain in the ass to deal with, and JACK, which is great for low-latency audio (making music) but overkill for most users. There is also OSS but nobody use that anymore except nerds.

From what I understand, Pipewire aims to unify the three existing layers into a single one, and manage video streaming as well.
If it works out fine, it could put Linux on the same level as CoreAudio for Mac when it comes to ease of use when dealing with audio, because there is nothing more annoying than messing with config files when you want to make music, and it would even allow artists with technical chops to do crazy stuff with distributed audio/video computing on top of that.

Moreover, the lead dev isn't Leonard Poettering but the author of GStreamer, who has a lot of experience in multimedia programming.

I've been using Winblow$ 10 for more than a year now solely because making music is simply easier with proprietary stuff, but I often miss Debian. If the Linux low-level multimedia infrastructure can finally rival proprietary systems, I'm all for it.

>>8534
Can't comment much about the rest except that GNOME sucks since version 3. MATE is my favorite DE.
There are legit gripes to have with SystemD (binary logs AFAIK), but a lot of hate for it stems for fizzbuzzing /g/tards who are abusing buzzwords to sound cool on the internet.

>>8534
>muh filepicker
Who the fuck even uses that. Just drag and drop.

>>8599
>There are legit gripes to have with SystemD
Do you know how horrible it feels to crash init by making a syntax error in a power management option?

>>8624
Who even needs to browse their filesystem?
If you cannot remember your directory structure, you should do a serious reorganization or cd moar.
When I extract an archive or download a torrent, I always write a script to sanitize the names (i.e. alphanumerics separated by underscores).

>>8626
systemd has no quality control and is overextended, but a rewrite with the fat cut off might be very good

>>8628
What is there in SystemD, that makes it redeemable?
There is no need to go back to SysVInit, now that we have minimal init systems like s6, runit and sinit.

>>8538
there are good projects out there
forget the birds eye view, and see the diverse ecosystem right in front of you. Pick what you like, and dont use the stuff you dont like. More normies are using linux than ever. This is good and bad. But as long as there's still a spectrum from more user friendly but shittier, to less user friendly (not necessarily but from windows user perspective) and more free, then it's fine. If the windows-impersonater side is getting bigger, just move people who use this stuff to better projects. Shoutout to Void, for using runit and being all around super minimalist and easy to use and great.

I wish I understood what youre all talking about :(

What's wrong with flatpak exactly?

>>11215
flatpak is ok, it's got some security features and it's got some disk space saving features. The NIX package-manager is probably nicer tho.

I think that it's best that software should go into normal distro repositories once it reached a level of maturity where it really doesn't matter if you don't have the absolutely latest version.

Flatpak & company are good for those peaces of software where you have to have the newest version.

>>11215
Pointless attempt by corporate suits to reinvent AppImages so that they can make money off repository hosting. Fills your computer up with crap by bypassing your package manager and using arcane directory trees.

>>11215
>Fills your computer up with crap by bypassing your package manager and using arcane directory trees.
Tbf this is a sane reaction to the still ongoing fallout from pushing dynamic linking onto every major OS. Closed source software and software with library breakage between version (which is most of modern linux atm) should always receive portable distributions, so it can run regardless of the whims of your distro's package maintainers and hardly-avoidable bitrot.

>>11240
>pushing dynamic linking onto every major OS
so what is your alternative smartass? shipping libraries with every app like retards on flathub do? and then then updating every instance of every library for every app lol?

lazy retarded shitapps devs use outdated libs and then cry at distro maintainers for updating libs that break their shitapps

>>11240
Why do you have proprietary software in your open and libre OS?
Package managers and sw repositories are one of the best features from most linux distros. Don't ruin it by bypassing it with yet another static package manager. AppImages are good enough for those cases.

>>11243
>so what is your alternative smartass?
Statically linked binaries work on every OS with ABI compatibility, that kernel developers usually take pains to preserve. They used to be a convenient distribution strategy, yet fell out of favor with the freedesktop crowd, supposedly for the reasons https://www.akkadia.org/drepper/no_static_linking.html outlines. https://gavinhoward.com/2021/10/static-linking-considered-harmful-considered-harmful/ provides a detailed counterargument, but in short:
<You can replace an .so with a binary compatible fixed version and update each of its reverse-dependencies without relinking.
This never happens in practice.
<Statically linked PIEs are impossible.
They were at the time. GCC officially supports them since 2017 and effectively since 2015.
<Sharing libraries saves memory.
Invocations of the same binary already share their text segment. Static linking also reduces space by copying only needed symbols and optimizing library code in local contexts. Therefore memory savings are often negligeable or even negative.
<At some point glibc introduced complex features requiring dynamic linking.
Most programs never rely on this functionality and static libraries exist to emulate their behavior.
<Static linking may violate the LGPL.
Circumventing the issue requires shipping the LGPL licensed library, then linking it to the incompatible binary at installation-time.
<Dynamic linking allows you to override functions at load-time.
This is only useful when debugging closed-source libraries and has expectedly spurred many security exploits.
>lazy retarded shitapps devs use outdated libs and then cry at distro maintainers for updating libs that break their shitapps
I just want my software to continue working. Even if it means holding onto one release of the software and manually installing it to any of my systems.
Software expecting to be dynamically linked is already annoying to statically link, because it only tracks direct library dependencies. Still somehow meson manages to hijack your compiler, so binaries are dynamically linked to your particular libc version, even when all dependencies are statically linked into the object.

>>11244
>Why do you have proprietary software in your open and libre OS?
The only proprietary software I use is video games and I don't even try old releases for linux anymore.
You shouldn't need to recompile any program only to link it to a new library release though and in case of an outdated codebase, you simply can't unless you want to rewrite all code relying on changed internals or interfaces that were deliberately broken.

>>11248
>I just want my software to continue working.
no your lazy ass just doesn't want to keep his shitapp up-to-date with the current libs
fuck off

I will side with distro maintainers over whiny devs any time of the day
I honestly like the Google approach to devs on their store
you don't want to use new APIs and keep your app up-to-date lazy bitch? get booted the fuck out

the same as what happens when an app gets booted the fuck off repo when updated libraries break it
good riddance

>>11249
Notice I wasn't talking about holding a gun to any package maintainers heads, forcing them to continue carrying software depending on 'libgnomeui'.
I just want the software I compile and track myself to continue working and I'm pissed at how poorly static linking is supported or actively sabotaged by the current freedesktop-centric linux ecosystem.

>>11249
is this fascism?

>>11252
Is it the violence and repression following an unsuccessful revolution against capitalism?

>>11252
no, you are the facist for wanting stable dependencies.

>>11253
Linux is an unsuccessful revolution against capitalism, and booting apps from the repo is violence and repression.

>>11252
no, it's setting the rules

>>11253
>Is it the violence and repression
there is always "violence and repression" against individuals who break the rules

>>11255
>and booting apps from the repo is violence and repression.
and?
go start your own distro if you don't like the rules

less whining more action, nerds

Step into the Void.

>>11248
>This never happens in practice.
What are you talking about. When there's a bug in openssl you get an update for openssl. Not everything that uses openssl. Static linking is essentially just copy and pasting the library into every executable that uses it. Now there's a bug in the library, how many of the 100s of executables on your system uses it and which versions were they compiled with? You have no way of knowing unless you kept the build logs.

>This is only useful when debugging closed-source libraries
How do you think things like torify and proxychains work.

>>11251
>I just want the software I compile and track myself to continue working
You know you don't have to compile against your disto's system libraries. You can maintain a completely separate userland in a chroot or container. Or use a secondary package manger like guix or nix.

>>11260
>guix
Pity it's maintained by a bunch of unstable wreckers. I have zero confidence in the future of that project.

>>11260
>What are you talking about.
Shared libraries are rarely ABI compatible with their previous versions, which is the reason for versioned symbols. Therefore it is standard procedure to update a package once a library dependency has changed. The previous package version would either have the package manager preserve an old library dependency specified by version or break at loadtime.
<Shared libraries are not a good thing in general. They add a lot of overhead in this case, but more importantly they also add lots of unnecessary dependencies and complexity, and almost no shared libraries are actually version-safe, so it adds absolutely zero upside.
https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=RcUSmQg@mail.gmail.com/
Linus agreed. Don't bother him about it.

>How do you think things like torify and proxychains work.
They are kludges. The recommended practice is to use HTTP_PROXY or firewall rules.

>guix
I lost all respect for guix when it pulled in rust, ruby, python, php, texlive, and cdparanoia to install something that should only depend on sbcl, libwebkit2gtk and libssl.
If a package manager may be installed on top of a base system, it should behave itself like pkgsrc.

>You know you don't have to compile against your disto's system libraries.
I do have multiple chroots and programs I wrote a wrapper for to enter them. It just seems like a waste and I can't find the appropriate userland for every specific program that couldn't keep up with the insanity.

>>11262
>Shared libraries are rarely ABI compatible with their previous versions
Incompetent library developers is not an argument against libraries themselves.

>Linus agreed.
The dude who is lubing up linux for rust insertion? That guy is my hero.

>They are kludges. The recommended practice is to use HTTP_PROXY or firewall rules.
And if the target doesn't support HTTP_PROXY? The point you're missing is that with LD_PRELOAD you the user can replace any shared library function with code you want. Which is something people rely on.

You also ignored the point that statically linking a library with security vulnerabilities creates a russian roulette situation where you don't know which executables are using which version of the suspect library. You don't even know which executables are even using the library.

>I do have multiple chroots and programs I wrote a wrapper for to enter them. It just seems like a waste and I can't find the appropriate userland for every specific program that couldn't keep up with the insanity.
Seems like self imposed insanity. If you're working at a company you don't get to choose your distro you might get stuck with a 10 year old version of CentOS. In which case a Debian chroot or Gentoo prefix will get you all the missing packages you want. I have to admit I don't understand what your problem is though.

>>11263
>where you don't know which executables are using which version of the suspect library. You don't even know which executables are even using the library.
lsof?

>>11263
>Incompetent library developers is not an argument against libraries themselves.
it's an argument against shared libraries in practice
especially when it's a rule and not an exception

"""theoretically""" shared libraries """could""" be ABI compatible

it's just that in practice they almost never are

you need to deal with the practical here, nobody cares about castles in the sky

>>8534
>You WILL use Pipewire
have problems with this shit right now

<linux sound architecture is a complete mess with layer over layer of complexity built on sand?
<I know! why don't we introduce ANOTHER layer of complexity on top!

>>11268
>you need to deal with the practical here, nobody cares about castles in the sky
yes, how about we deal with the practicals here fag

A few minutes ago I installed freetube from flathub which pulled 2GB runtime for a 90MB binary

flatpak doesn't have delta updates
now imagine updating this shit

and I'm not even talking about security considerations of devs bundling outdated libs with their apps
if you trust that sandbox will protect you against a library vulnerability - then you're a fool

>>11269
>on top
pipewire is designed to be used with nothing else but alsa

>>11262
>I lost all respect for guix when it pulled in rust, ruby, python, php, texlive, and cdparanoia to install something that should only depend on sbcl, libwebkit2gtk and libssl.
You can use package parameters to delete dependencies you don't want but it's not automatic which is annoying and I wish they would fix it.

>>11308
So what's the deal with the whole guix/nix package managing?
Does it work in practice as advertised - reproducible builds, single config in scheme or whatever, rolling release distro that doesn't regularly break on upgrades (finally), source repo - binary third party cache that you don't have to trust, config portability etc etc?

>Compared to traditional package managers, Guix package stores can grow considerably bigger and therefore require more bandwidth; although compared to container solutions (like Docker) that are also commonly employed to solve dependency hell, Guix is leaner and conforms to practices like Don't repeat yourself and Single source of truth. If the user chooses to build everything from source even larger storage space and bandwidth is required.
This shit sounds insane
too good to be true

what's the catch?
and what's the deal with the whole Hurd business? This shit is older than me and still not working..

>>11308
also what is the packaging process?
why is an official package allowed to pull bullshit deps? who maintains this shit how did it pass peer review?

>>11312
>Does it work in practice as advertised - reproducible builds, single config in scheme or whatever, rolling release distro that doesn't regularly break on upgrades (finally), source repo - binary third party cache that you don't have to trust, config portability etc etc?
yeah pretty much. there are a few annoying bugs and in practice you need more than one config file. i have a tree of config files i sync between computers with git (it's still tiny though). and i don't have the time to switch to guix home so i keep backups of my home subvolumes.

>This shit sounds insane
>too good to be true
guix/nix use less storage space than flatpak/appimage/docker etc. because they actually solve the dependency problem correctly and the others don't, they just go "fuck it" and vendor libraries in giant blobs, which get duplicated and outdated. it's possible to use even less storage space by making package features configurable and using more esoteric technologies like content-addressable-stores, but such a thing doesn't exist yet

>what's the catch?
guix system is still kind of unpolished and missing services and stuff. i don't use nixos but i've heard people bitching that its UI sucks. the functional dependencies model means if you patch a package you have to rebuild everything that depends on it, but guix has a mechanism called "grafts" so you don't have to re-download the entire package every time it's updated. packages with few dependencies get updated much more frequently than packages with a huge number of dependencies (like glibc)

>and what's the deal with the whole Hurd business? This shit is older than me and still not working..
it's still incomplete because they basically used it as a platform for OS research for a couple decades instead of trying to make it usable. there's a treasure trove of OS design information on the hurd wiki. there's like 5 people working on it now. they're close to getting 64bit kernelland and SMP working. there's a guix VM image available for hurd. obviously the linux version will be available for the forseeable future (despite the fact that they did an april fools where they said they would be switching to hurd)

>>11313
>also what is the packaging process?
https://guix.gnu.org/en/blog/2018/a-packaging-tutorial-for-guix/
https://guix.gnu.org/manual/en/html_node/Contributing.html
though for certain types of packages, you can just run "guix import" and it will autogenerate a package for you

>why is an official package allowed to pull bullshit deps?
packages are built with nearly all features enabled. also the dependencies are completely isolated so if you install guix on another distro it will use none of the packages from your distro as dependencies. you can modify the packages however you want but there's no built-in mechanism to make that easy like useflags, which i think is a flaw. also you will have to build it yourself because the build servers do not have enough resources to build every possible version of a package. they have plans to turn guix into a p2p network where clients can pass around built packages in a grid computing thing, and that might make configurable packages and binaries possible at the same time

>>11312
>what's the catch?
oh yeah, guix likely won't work on your hardware unless you install nonguix

>>11312
>what's the catch?
oh and something else, all packages in guix have to be "bootstrapped", meaning built from pure source code, because there's a method of inserting malware into a binary called a thompson compiler attack. guix is basically the only distro that is completely committed to being secure against this vulnerability so they don't package programs using languages that are not bootstrapped (this includes kotlin, ada, and javascript), so you can't package those things until you bootstrap the language first.
https://bootstrappable.org/
https://dustycloud.org/blog/javascript-packaging-dystopia/

also KDE isn't available on guix yet. there's a patchset for it on the mailing list that is still being reviewed.

and selinux doesn't work on guix/nix, if you care about that

>>11317
>so you can't package those things until you bootstrap the language first.
there's actually a channel for beta-quality packages that upstream won't accept, you might be able to find it there or submit patches to them
https://git.sr.ht/~whereiseveryone/guixrus

>>11319
>there are undercover cops roaming around the net
Lol, hi, Officer!

>>8562
Iktf

>>11305
>pulled 2GB runtime for a 90MB binary
kek, that's what Electron app running in a flatpak runtime looks like. Still more sane than Steam runtime running in a flatpak runtime tho…

>>8534
>You WILL use Pipewire
based
>You WILL use Wayland
cringe (no xterm, XMonad)
>You WILL use systemD
based
>You WILL install everything from Flatpak
ultra cringe, use nix
>You WILL use GNOME
based
>You WILL use GTK
based
>You WILL NOT have thumbnails in the filepicker
cringe, is this 19 year old bug still not fixed? https://gitlab.gnome.org/GNOME/gtk/-/issues/233
>You WILL use btrfs
based
>You WILL accept the code of conduct
conduct deez nuts
>And you WILL be happy
cringe. pure ideology.