I ordered something from someone awhile back and it came with a free flash drive in the shape of a credit card. It had pictures of puppies on it so naturally it's a puppy linux drive now.
This is entirely irrelevant but hopefully someone gets a smile out of it.
Thin, credit-card-sized USB drives are a popular promotional gimmick because they have a practical use but also have a large surface area for promoting your brand. Most often given out as vendor gifts.
is there a way to make it work like a rolling release of sorts? i'd want to use debian, but i don't want to stay with old packages and wait 2 years for an update
You could use debian testing. It's a somewhat "rolling-release" model. You will get more up to date packages with more stability too.
You could also use unstable, but I wouldn't recommend it personally.
Edit: if you really need the most up to date version of some packages, you can pin them to use the unstable repo. This would be a pretty reasonable solution.
As will have debian unstable. That's the way it goes, for a few months every few years it slows down until the new stable gets released. Testing is just 10 days after unstable to avoid the biggest bugs.
Never had big problems with debian unstable in 15 years though, as long as you use apt-listbugs
I've daily drivered arch for a couple months now. Only a few time have I not searched and found a wiki/forum with the precise error/comment and a solution/fix for the problem.
If you're moderately comfortable with the command line, Arch is amazing. I find it considerably easier to find software I want to install, and find answers to problems I have.
I would say that if you're not interested in learning when something goes wrong, so you're not really interested in anything other than i don't care I just want it to work then it's not the distro for you.
The rolling release style is really great and Arch is rock solid, so if you are looking for something a little more user friendly, Endeavor is worth a try as it is Arch based but focused on an easier to use system.
I installed Arch for the first time in March of last year for my primary gaming PC. Previously my gaming PCs were windows but I keep a separate file server and HTPC each running Ubuntu. I'm in the process of switching both of them over to Arch now because I just consider package management and updates so much easier.
There's the primary maintained software repository, then there's the AUR. I think most of the times people's systems break because as inexperienced users they find a specific piece of software a site told them to install and its only available in the AUR, instead of finding something properly maintained that already exists to do the same thing. Over time you end up with a mess of a system relying on user maintained build files.
I learned a lot in my first year of Arch (probably my 15th+ year of Linux though and I was not afraid of the command line) so I decided to reinstall my system after that first year and one of the choices I made was to not use AUR packages (except in very specific cases). I also changed bootloader's and a few other things.
I've had mine break twice I think. The first time was because I didn't know the general rule was "if you're doing an update, update everything". I saw an updated GPU driver was released so I installed it, but didn't bother with anything else. Turns out you're supposed to update the graphics drivers and kernel at the same time, so i wasn't getting output after booting the kernel. The beauty of Arch though is that when you learn to install it, you also learn how to fix it. Booted off the USB installer stick, mounted my root partition, chrooted to it, then ran a system update. I was back booted up, logged in, and gaming in less than 10 minutes from discovering the problem.
In general, I would say people's systems getting bricked "all the time" is a bit hyperbolic.
even those deb files that only run on Ubuntu for some damn reason on my Debiain system.
FUCK i understand now! the software i wanted to install had a .deb but its website said it was for ubuntu 20.04, no wonder it didn't work on a debian container!
it didn't work, but i soon found out by looking at it's entry on the AUR that the package is itself broken, not the distro environment it's supposed to be installed on
Arch User Repository. If you're using Arch, you get the basic stuff from the official repositories. But for most programs there's the AUR. They're often less polished, some of it may be proprietary. There are package managers dedicated for it, that also know to handle the official repositories.
Hey, I see you tried to make this link: Read more, but you did it wrong. The exclamation mark (!) in front of a link is used for embedding media.
Tip: You can embed image into link to create a button
Just switched a couple of my systems from Pop and Fedora (gnome) to Debian 12 w/ KDE Plasma.
All in l I like it. I don’t like where Canonical or RedHat are moving, for the FOSS consumer. Canonical is making huge strides as an enterprise distro but for home use I’ve really moved away from it since Unity.
Originally I went Fedora because my office was a RHEL shop but we’re moving towards Ubuntu.
Thankfully RHEL/Centos/Fedora also get attention thanks to the large corporate influence.
Anything else can just be compiled from scratch, after spending 6 hours trying to figure out what ajfiwn-0-libs-dev is in redhat land, only to find out it was libfiwn-devel all along.
distrobox: Tool for creating one-off containers of a different Linux distro.
container: A virtual OS environment that runs on your computer, but doesn't know that it's running in your computer. It's not the same as a VM or emulator.
flatpak: A tool designed by RedHat for running sandboxed Linux programs in any environment. Flatpak can either refer to the system as a whole (eg: "You need to install flatpak on your machine to use our tools") or an individual program packaged for the flatpak system (eg: "You must download the latest flatpak of Firefox").
AUR: The Arch User Repository. A collection of installation scripts to add software to Arch Linux. These scripts are not owned or maintained by anyone officially affiliated with Arch, so you can find AUR packages for almost anything.
So, the comment becomes: Stick it in a dedicated environment designed to run Debian. Then package it so anyone can run it. Then make it easy for anyone running Arch Linux to install it.
I don't know what the Linux community's consensus on appimages are, but I wouldn't mind if people made more appimages because, for the few distros I've used, appimages just usually work.
AppImages are definitely convient to use. However the two issues I have with them are that there's no easy way to find them (eg flathub) and they're not automatically integrated with the DE. Requiring a tool that manages AppImages to make it easier.
Only n00bs code their programs from scratch. Cool people build their own kernel, OS, compiler, and coding language, and they already have that program built in.
Only n00bs build their own kernel, OS, compiler, and coding language, and they already have that program built in. Cool people create their own universe, with different laws of physics and constants, then they make it act as a whole computing entity capable of anything, it then creates a simulation in which we discuss this stuff.
Arch is viable because the AUR is full of converted debs and package managers keep things up to date. Most distros have a method to install this kind of software but honestly universal out of the box flatpak support can’t come soon enough for consumer distros. We need canonical to give up on snap for Ubuntu desktop
Debtap is suprisingly easy to use after switching to arch (highly recommend), but i actually love .deb files. Obviously it's a slight risk to the user in the similar way
dot EXE's can be for windows , but they really do simplify package management for when you're newer to linux.
BlendOS Will let you install virtually any package format through containerization, but it shows up just as if it was a native app. It's pretty neat to see and I hope more distros adopt this
I'm on Gentoo for example. I can write an ebuild to automatically download said deb, extract it, install it with the package manager... And if the site has any semblance of organization involved, I can write one ebuild that will always download the version specified in its name, so when there is an update, I can copy the ebuild, change its name to new version and if the dependencies or structure didn't change, it will install just fine without any work.
I am quite comfortable finding my way around ArchLinux, and recently decided to give Gentoo a try. I didn't expect it to be that much harder but all the cflags, emerge, conflicts and updates feels like black magic. I guess that if you know your way around Gentoo, reverse-engineering a deb file is not a real challenge. However I'm assuming that most Linux users would hope for a less involved solution.
Stability, slow changes, predictable, strong history, lots of distributions are based on it, the list goes on and on. I don't use it but it's kinda stupid to question it's relevant qualities considering how much it's brought to the Linux community.
And again...
Distrobox is your friend. Me, I like an immutable OS (kinoite) but I still want the AUR…
distrobox-create --name arch --image archlinux:latest
distrobox enter arch
install yay as normal
yay -S vscodium
distrobox-export --app vscodium
yay exa
distrobox-export --bin /usr/sbin/exa
exit [back to kinoite]
exa [works]
vscodium [works, has icon in application launcher]
Well it does technically, the issue we're talking about is how it's packaged, one you extract the package the software will work just the same (assuming there aren't any version mismatches between kernel modules). DEBs (Debian based distros) and RPMs (RedHat based distros) are the two biggest package formats, the next common format is a tar ball.
Add to this, this gives birth to more modern packaging format like flatpak, appimage, and snap, that works across all distro with proper permission control.
Now for most graphical apps, you just search on the app store and click install, like a iphone user.
I think you might be talking about two group of Linux user. I think majority of the user realized that shared dependency is not scalable in the recent couple years, yet there are still a loud minority that oppose dupilicated dependencies that exists in these universal formats.
Finally, I think the three universal package formats provide better sandboxing support than msi. But appx in windows are very much inline with these packaging formats.
Kernel develipers, libraries developers, compiler developers, distro maintainers, mirrors hosters, anyone whose system runs not on few terabytes disk and gigabit internet.
I heard some geniuses put entire graphical drivers into snap/flatpak/appimages.
Different app depends on different version of the underlying softwares. In the old days distro packages apps, however it would cause dependency hell.
Hence with the development in containers, universal packaging format prevails, where each app is packaged with all of its dependencies. so that the system dont need to maintain the dependency of every single app people want to use.
Different app depends on different version of the underlying softwares.
On different ranges of versions. Usually something like "1.2 or newer". With few exceptions that break ABI every year(looking at you, Boost) or 11 times a month(it is rust, who would have guessed). If everything was as hard as you described, then there is no way for me to play UT2004 back from, you guessed it, 2004. But I did, and all I needed just to install few 32-bit version of libraries and run it with OSS(very old audio api) emulation.
however it would cause dependency hell.
No, task of package manager is to solve dependency hell
universal packaging format
We had 2 universal packaging formats, now we have 5 universal packaging formats and two container types.
where each app is packaged with all of its dependencies.
Which in case of UT2004 means packaged with all exploits back from 2004.
There are different aspect to the same product. IPhone is lockeddown and aniconsumer, but it doesn't mean every aspect of it is not worth taking a lesson from.
In order for linux to have mass apeal, it will need to be simple by default, and that is where the app store model shines, you just search and click install, everyone can figure that out.
But that doesn't imply linux has to be lockdown and anticonsumer like iphone. If you want to compile your own kernel, you should have freedom to do so.
The software itself should run, but the installers themselves use different standards. I'm pretty sure you could set up your own distro to use installers from different one, though it may require some work.
Windows kind of has that too, with all the .MSI, .exe, .msix and all the appxpackages and how almost none of that works out of the box anymore because you'd otherwise be able to install another browser without opening edge once
Yeah, Valve sucks with the "we're not rewriting this for 64 bit because there's no benefit" stance. It's a pain in the ass to use on Linux because you have to have the 32 bit counterpart of everything it uses alongside the 64 bit counterpart that literally everything else uses. You would think they would finally decide to rewrite it since they're a major Linux contributor, and their handheld runs Linux.
Fortunately, using a neat tool called Whisky, I’m able to install the Windows Steam client, from which I can download and play the Portal games, because they’re proper. But that’s M1/2 only.
Since you mentioned you've never used Linux, you may find it amusing that similar windows compatibility software exists for Linux and is called Wine. Whisky and Wine.
Nice, a lot of the games work out of the box with the Linux client, you just need to enable support for unsupported games for Proton on the Steam settings.
last time I used Mac, I still need to go online and grab the dmg file (or whatever the extension of the file is) myself, since most app is not avaliable in the app store, like jetbrains app and adobe apps.
It's just maintaining arch that was a bit of a headache for me. I loved having access to the AUR and being able to use bleeding edge.. well, everything. But too much of my time ended up going to fixing issues after updates or finding out what package to choose when there were conflicts during updates.
Open it up in midnight commander, and it will unpack it into a virtual directory structure, complete with install/uninstall scripts.
Look at the install script to see what it's thinking, pull out the file structure, copy into your filesystem.
Oh, and hope. Because often you need to get matching glibc and other dynamic libraries that the program was compiled against. Which isn't the end of the world as the dynamic linker will look in the local directory where the program is first for libraries, but it becomes a hassle pretty quickly.
What could possibly go wrong with running precompiled binaries that were linked to a set of precompiled libraries with a completely different set of precompiled libraries.
You're not wrong, it's definitely not something a n00b should attempt in most cases. But I've done this before to save myself the need for distrobox. A lot of proprietary software only offers .deb, but is usually either statically linked or comes with its own set of nearly all the libraries it needs. So just extracting and running it often does the trick on non-debian distros like Fedora in my case.
Seriously though, just use distrobox or see if there's an unofficial package for your distro that you trust (AUR/copr/ppa/OBS). It's more straight forward especially if you don't know what you're doing.
Not the locations. The versions. Your libssl-1.0 isn't the same as mine. There often are differences in major, minor or patch versions. There even are differences in compile options where a feature present in one is not compiled in another. E.g. ciphers available in libssl.
me, who definitely knows how to and in fact totally prefers to build everything from source: [nervous laughter] yeah what kinda dingus exclusively uses .debs amirite?
Software has a Linux version and it only comes as a .deb
Depends on a load of packages exclusive to Ubuntu and installing it on stock Debian is bloody impossible
Yeah I remember when Steam came to Linux. Never got it to work. I hope it is better nowadays? (Sadly can't check. My only pure Linux box at the moment is a Raspberry Pi, I don't expect Steam to run on that either)
You can get Steam on just about any distro, for years at this point. And there's always Flatpak for these cases too although for Steam I recommend native packages.
it doesn't matter which one is better, it's about compatibily, and there's no way to install .debs on, like, rpm based distros without getting completely broken uninstallable packages
Distrobox is the way. Running Fedora and I have debian and arch boxes (with their own home dir) installed. Graphical applications work without any fuss and I have yet to run into an issue.
Well the solution here is to just use the superior distro, naturally.
This post will surely upset nobody.
Finally, puppy linux is getting the recognition it deserves
I ordered something from someone awhile back and it came with a free flash drive in the shape of a credit card. It had pictures of puppies on it so naturally it's a puppy linux drive now.
This is entirely irrelevant but hopefully someone gets a smile out of it.
Wait, what?
Thin, credit-card-sized USB drives are a popular promotional gimmick because they have a practical use but also have a large surface area for promoting your brand. Most often given out as vendor gifts.
Weird, but interesting!
If you donate to the FSF, you get a member card with pre-installed Linux.
and GNU?
I think you mean Hannah Montana Linux.
Puppy ftw
Puppy's awesome. I've used it on a laptop so old I had to install a bootloader in the MBR so it would boot from USB. It ran like a dream.
Red Hat 5.0 for lyfe.
Kernel 2.0.36 represent! ✊
When did TempleOS start supporting .deb files?
Agreed. Debian Linux is just a children distro with a fibonacci logo that god created.
You're right! If a deb file exists then surely it's in the AUR. ABS will repackage it seamlessly for you and then install it directly with Pacman.
Btw I use Arch
TRIGGERED
Linux mint ftw
BRB. Sharpening my teeth.
is there a way to make it work like a rolling release of sorts? i'd want to use debian, but i don't want to stay with old packages and wait 2 years for an update
You could use debian testing. It's a somewhat "rolling-release" model. You will get more up to date packages with more stability too.
You could also use unstable, but I wouldn't recommend it personally.
Edit: if you really need the most up to date version of some packages, you can pin them to use the unstable repo. This would be a pretty reasonable solution.
You could just go with Debian unstable. I rarely ran into issues while running it in a rolling release style.
Debian testing might also work for you. But it will have a freeze window before each release.
As will have debian unstable. That's the way it goes, for a few months every few years it slows down until the new stable gets released. Testing is just 10 days after unstable to avoid the biggest bugs.
Never had big problems with debian unstable in 15 years though, as long as you use apt-listbugs
sparky Linux is based on Debian and it has stable and rolling release
Most of such packages, be it deb rpm or really whatever, have their AUR entry, install and run fine on Arch.
Savage. 💣
I don't care I use Arch BTW. Someone would have made a AUR package for it by now.
Most of the air is converted deb
Can you breathe converted deb?
Let me try and get bac....
So nice of you to hit send before passing out. You're a true hero.
hopefully he didn't bat
I would have never guessed an Arch linux user would go by reddit_sux
My other fediverse account is [email protected] just to hammer the point even more.
As someone who's used debian based distros for 20+ years now, I see no issue with this. ;)
I use Debian btw
Testing or bust.
Bookworm
Sid on home PC, Bookworm on work laptop
As an Ubuntu user of 17+ years, I concur.
Only problem is remembering to keep it updated.
Even worse: the .deb file's dependences are only available in a specific version of Ubuntu LTS or with PPAs.
Then we should appreciate them. Is it fair to call them neckbeards when they toil away at the code coalface for our benefit?
Well ... do they have a neckbeard? /s
Fucking gyrenes, where'd all my crayons go?!
Shit half the time it's right in the main repo under Extra.
This is why Arch is the best. Forget the rolling release, it's the sheer size of the repos for me.
I've daily drivered arch for a couple months now. Only a few time have I not searched and found a wiki/forum with the precise error/comment and a solution/fix for the problem.
It's almost literally insane.
How would you compare it to Ubuntu? I have never tried Arch before.
Well for a start it's compulsory to tell everyone you use it.
I'm going from Ubuntu 16 or so (took a break since then). The flexibility/customization/wikis of arch make it better IMO
If you're moderately comfortable with the command line, Arch is amazing. I find it considerably easier to find software I want to install, and find answers to problems I have.
I would say that if you're not interested in
learningwhen something goes wrong, so you're not really interested in anything other thani don't care I just want it to workthen it's not the distro for you.The rolling release style is really great and Arch is rock solid, so if you are looking for something a little more user friendly, Endeavor is worth a try as it is Arch based but focused on an easier to use system.
I installed Arch for the first time in March of last year for my primary gaming PC. Previously my gaming PCs were windows but I keep a separate file server and HTPC each running Ubuntu. I'm in the process of switching both of them over to Arch now because I just consider package management and updates so much easier.
Truly don't mean to be argumentative, but, I read all the time how an update will semi-brick it, requiring repair. ?
Happens every once in a while but usually it's a trivial repair
There's the primary maintained software repository, then there's the AUR. I think most of the times people's systems break because as inexperienced users they find a specific piece of software a site told them to install and its only available in the AUR, instead of finding something properly maintained that already exists to do the same thing. Over time you end up with a mess of a system relying on user maintained build files.
I learned a lot in my first year of Arch (probably my 15th+ year of Linux though and I was not afraid of the command line) so I decided to reinstall my system after that first year and one of the choices I made was to not use AUR packages (except in very specific cases). I also changed bootloader's and a few other things.
I've had mine break twice I think. The first time was because I didn't know the general rule was "if you're doing an update, update everything". I saw an updated GPU driver was released so I installed it, but didn't bother with anything else. Turns out you're supposed to update the graphics drivers and kernel at the same time, so i wasn't getting output after booting the kernel. The beauty of Arch though is that when you learn to install it, you also learn how to fix it. Booted off the USB installer stick, mounted my root partition, chrooted to it, then ran a system update. I was back booted up, logged in, and gaming in less than 10 minutes from discovering the problem.
In general, I would say people's systems getting bricked "all the time" is a bit hyperbolic.
Or the OpenSUSE OBS instance for OpenSUSE, it has repositories with packages for almost anything.
It's kind of hard to find but you can browse everything at http://software.opensuse.org
Nothing Distrobox can't fix. I can run AUR, RPM, and even those deb files that only run on Ubuntu for some damn reason on my Debiain system.
It's probably already in your default repos too.
FUCK i understand now! the software i wanted to install had a .deb but its website said it was for ubuntu 20.04, no wonder it didn't work on a debian container!
i'll try this RIGHT NOW, hope it works!
it didn't work, but i soon found out by looking at it's entry on the AUR that the package is itself broken, not the distro environment it's supposed to be installed on
It's seriously frustrating. I had this happen just last night, but fortunately I was able to get the app I needed another way.
This shit is crazy thanks for letting me know
What about Cisco packet tracer?
It's worth a shot!
How does distro box do with more complicated gui based applications?
The only thing I've had problems with is a VPN
Yup. Should work fine. I know some people use this to get Divinci Resolve to work on Ubuntu.
Give it 2 days and chances are someone has already published a PKGBUILD in the AUR
aur?
Arch User Repository. If you're using Arch, you get the basic stuff from the official repositories. But for most programs there's the AUR. They're often less polished, some of it may be proprietary. There are package managers dedicated for it, that also know to handle the official repositories.
Hey, I see you tried to make this link: Read more, but you did it wrong. The exclamation mark (
!) in front of a link is used for embedding media.Tip: You can embed image into link to create a button
Btw are you a bot or not
I am not a bot. (I believe)
Ain’t my fault you forgot about
dpkg -i;-)I remember alien back in the day.
Edit: holy shit this is still maintained https://wiki.debian.org/Alien
The struggles of a Linux user
holy shit i had no idea lol
This is why you use glorious Debian.
Just switched a couple of my systems from Pop and Fedora (gnome) to Debian 12 w/ KDE Plasma.
All in l I like it. I don’t like where Canonical or RedHat are moving, for the FOSS consumer. Canonical is making huge strides as an enterprise distro but for home use I’ve really moved away from it since Unity.
Originally I went Fedora because my office was a RHEL shop but we’re moving towards Ubuntu.
I'm a light Linux user with windows 11 on my work dev machine.
I started using Linux Mint and it's the right speed for me. Switched to Mint LMDE 6. It's smooth.
(☝◞‸◟)☞
Thankfully RHEL/Centos/Fedora also get attention thanks to the large corporate influence.
Anything else can just be compiled from scratch, after spending 6 hours trying to figure out what ajfiwn-0-libs-dev is in redhat land, only to find out it was libfiwn-devel all along.
pkgs.org with
pkgconifg(package-name)as the search string: let me introduce myselfNobody needs a website, literally just
dnf install "pkgconfig(libfoo-1)"ordnf install /usr/include/fooheader.h. Most sane package manager ever.That's a thing?? Amazing, I just found out about this not long ago, now seeing that being integrated in the package manager too is next level!
It’s actually just metadata in the rpms, nothing special. OpenSUSE adds even more like “typelib(Gtk-3.0)”.
stick it into a distrobox container and then package that into a flatpak on the AUR. 😎👍
I know all the words that aren't nouns in that sentence!
distrobox: Tool for creating one-off containers of a different Linux distro.
container: A virtual OS environment that runs on your computer, but doesn't know that it's running in your computer. It's not the same as a VM or emulator.
flatpak: A tool designed by RedHat for running sandboxed Linux programs in any environment. Flatpak can either refer to the system as a whole (eg: "You need to install flatpak on your machine to use our tools") or an individual program packaged for the flatpak system (eg: "You must download the latest flatpak of Firefox").
AUR: The Arch User Repository. A collection of installation scripts to add software to Arch Linux. These scripts are not owned or maintained by anyone officially affiliated with Arch, so you can find AUR packages for almost anything.
So, the comment becomes: Stick it in a dedicated environment designed to run Debian. Then package it so anyone can run it. Then make it easy for anyone running Arch Linux to install it.
flatpak... is unrelated to redhat, at least at the moment
it was initially made as a side project by a person who worked at red hat on containers, nowadays it's developed by freedesktop.org
I don't know what the Linux community's consensus on appimages are, but I wouldn't mind if people made more appimages because, for the few distros I've used, appimages just usually work.
AppImages are definitely convient to use. However the two issues I have with them are that there's no easy way to find them (eg flathub) and they're not automatically integrated with the DE. Requiring a tool that manages AppImages to make it easier.
Appimages are supposed to be distributed the same way Windows and Mac software is distributed, that's kind of the point.
As for management, I agree distros should ship with an appimage manager.
Only n00bs install packages. Cool people compile from source.
That's still just mid level. Cool people codes everything from scratch by just looking at some pictures
Only n00bs code their programs from scratch. Cool people build their own kernel, OS, compiler, and coding language, and they already have that program built in.
I did, but I also made my own internet and it gets lonely there.
Like that schizo guy who did TempleOS. The ultimate computer man.
Only n00bs build their own kernel, OS, compiler, and coding language, and they already have that program built in. Cool people create their own universe, with different laws of physics and constants, then they make it act as a whole computing entity capable of anything, it then creates a simulation in which we discuss this stuff.
Cool people link the relevant xkcd
Laughs in soldering logic gates out of vacuum tubes.
You amateurs and your software, real programmers work in lead and tin.
That's nothing, only n00bs do that. Cool people code in binary; the real programming language.
Wrong, they use butterflies.
TempleOS has entered the chat.
Only available as Deb file.
He forgot to compile reading comprehension from source.
He is so cool that he is reverse engineering the source and compiling from there.
HE'S TRYING TO INSTALL PROPRIETARY SOFTWARE!!! GET THE TORCHES AND PITCHFORKS!!!!
https://sourceforge.net/projects/alien-pkg-convert/
It's only been around like forever.
I was gonna say "has no one in here heard of alien?". I've rarely ever had to use it... because I use Arch.
alien never worked for me, i tried once but it led to an unistallable package
Lol
He is technically correct, the best kind of correct.
Arch is viable because the AUR is full of converted debs and package managers keep things up to date. Most distros have a method to install this kind of software but honestly universal out of the box flatpak support can’t come soon enough for consumer distros. We need canonical to give up on snap for Ubuntu desktop
Debtap is suprisingly easy to use after switching to arch (highly recommend), but i actually love .deb files. Obviously it's a slight risk to the user in the similar way dot EXE's can be for windows , but they really do simplify package management for when you're newer to linux.
We don't have this kind of weakness on Arch. Apes together strong. Porting magic language to our world.
We still need to fix their deb only release
BlendOS Will let you install virtually any package format through containerization, but it shows up just as if it was a native app. It's pretty neat to see and I hope more distros adopt this
Someone explain this to my dumb ass.
Deb files are debian packages, so if you're not on debian you can't install it
I don't understand why would people not be on debian does not compute
I'm on Gentoo for example. I can write an ebuild to automatically download said deb, extract it, install it with the package manager... And if the site has any semblance of organization involved, I can write one ebuild that will always download the version specified in its name, so when there is an update, I can copy the ebuild, change its name to new version and if the dependencies or structure didn't change, it will install just fine without any work.
I am quite comfortable finding my way around ArchLinux, and recently decided to give Gentoo a try. I didn't expect it to be that much harder but all the cflags, emerge, conflicts and updates feels like black magic. I guess that if you know your way around Gentoo, reverse-engineering a deb file is not a real challenge. However I'm assuming that most Linux users would hope for a less involved solution.
That sounds really cool.
You could check out NixOS :)
I don't understand why someone would want to be on Debian, what actual advantage does it have.
Stability, slow changes, predictable, strong history, lots of distributions are based on it, the list goes on and on. I don't use it but it's kinda stupid to question it's relevant qualities considering how much it's brought to the Linux community.
Also don't forget that Debian is completely community driven, unlike Redhat's distros which face some controversy.
Lots of distros are based on Ubuntu, does that make Ubuntu an amazing distro?
They are based on Debian then, not Ubuntu. They are just reworked.
They are based on both in that case
Relax, guys, Debian and not Debian both have their pros and cons. The variety of options is what's so beautiful about Linux.
For the .deb packages, obviously.
Did you not read the post?
If it is only available as a .deb, it is probably targeting Ubuntu specifically.
Ubuntu is a derivative of Debian and uses the same package format. Ubuntu is much more popular though and the packages are not completely compatible.
Did you mean versus another Debian derivative like PopOS, or versus a non-Debian derivative like Fedora, etc.?
… Debian, or one of the many excellent Debian-based distros
Where distrobox
My dumbass without DistroBox:
And again... Distrobox is your friend. Me, I like an immutable OS (kinoite) but I still want the AUR…
Try it, you might like it !
Ah, a wild deb-file. Let's add it to my frankendebian.
As someone who’s never used Linux, TIL that software doesn’t work across all flavours of Linux.
Well it does technically, the issue we're talking about is how it's packaged, one you extract the package the software will work just the same (assuming there aren't any version mismatches between kernel modules). DEBs (Debian based distros) and RPMs (RedHat based distros) are the two biggest package formats, the next common format is a tar ball.
Add to this, this gives birth to more modern packaging format like flatpak, appimage, and snap, that works across all distro with proper permission control.
Now for most graphical apps, you just search on the app store and click install, like a iphone user.
Don't mention the S-word here, some people might come out of their basement to tell you how it's the worst thing since proprietary software.
I think you might be talking about two group of Linux user. I think majority of the user realized that shared dependency is not scalable in the recent couple years, yet there are still a loud minority that oppose dupilicated dependencies that exists in these universal formats.
Finally, I think the three universal package formats provide better sandboxing support than msi. But appx in windows are very much inline with these packaging formats.
Explain yourself.
Kernel develipers, libraries developers, compiler developers, distro maintainers, mirrors hosters, anyone whose system runs not on few terabytes disk and gigabit internet.
I heard some geniuses put entire graphical drivers into snap/flatpak/appimages.
Correct me if I am wrong.
Different app depends on different version of the underlying softwares. In the old days distro packages apps, however it would cause dependency hell.
Hence with the development in containers, universal packaging format prevails, where each app is packaged with all of its dependencies. so that the system dont need to maintain the dependency of every single app people want to use.
On different ranges of versions. Usually something like "1.2 or newer". With few exceptions that break ABI every year(looking at you, Boost) or 11 times a month(it is rust, who would have guessed). If everything was as hard as you described, then there is no way for me to play UT2004 back from, you guessed it, 2004. But I did, and all I needed just to install few 32-bit version of libraries and run it with OSS(very old audio api) emulation.
No, task of package manager is to solve dependency hell
We had 2 universal packaging formats, now we have 5 universal packaging formats and two container types.
Which in case of UT2004 means packaged with all exploits back from 2004.
I DON'T WANT THIS
https://www.youtube.com/shorts/59dQ-5sjDLc
Iphone is most locked-down anti-consumer pile of garbage and this is how you defend it?
There are different aspect to the same product. IPhone is lockeddown and aniconsumer, but it doesn't mean every aspect of it is not worth taking a lesson from.
In order for linux to have mass apeal, it will need to be simple by default, and that is where the app store model shines, you just search and click install, everyone can figure that out.
But that doesn't imply linux has to be lockdown and anticonsumer like iphone. If you want to compile your own kernel, you should have freedom to do so.
This is how linux works for last 30 years...
Here is an alternative Piped link(s):
https://www.piped.video/shorts/59dQ-5sjDLc
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I'm open-source; check me out at GitHub.
The software itself should run, but the installers themselves use different standards. I'm pretty sure you could set up your own distro to use installers from different one, though it may require some work.
now you know 😫
Windows kind of has that too, with all the .MSI, .exe, .msix and all the appxpackages and how almost none of that works out of the box anymore because you'd otherwise be able to install another browser without opening edge once
I’m a Mac user, so they made it as simple as possible for our simple brains. That said, no old 32bit Steam games for me ☹️
Yeah, Valve sucks with the "we're not rewriting this for 64 bit because there's no benefit" stance. It's a pain in the ass to use on Linux because you have to have the 32 bit counterpart of everything it uses alongside the 64 bit counterpart that literally everything else uses. You would think they would finally decide to rewrite it since they're a major Linux contributor, and their handheld runs Linux.
Fortunately, using a neat tool called Whisky, I’m able to install the Windows Steam client, from which I can download and play the Portal games, because they’re proper. But that’s M1/2 only.
Since you mentioned you've never used Linux, you may find it amusing that similar windows compatibility software exists for Linux and is called Wine. Whisky and Wine.
Yeah, Wine is a thing on Mac too. Never really dug too far into it though. Whisky is easy to use though.
Whisky is just a Wine wrapper. It's still Wine under the hood.
Nice, a lot of the games work out of the box with the Linux client, you just need to enable support for unsupported games for Proton on the Steam settings.
last time I used Mac, I still need to go online and grab the dmg file (or whatever the extension of the file is) myself, since most app is not avaliable in the app store, like jetbrains app and adobe apps.
Is it still the case?
Yeah, that’s most often the case. I very rarely install from the App Store unless the software I’m after has a link on their site.
Debtap to the rescue
su alien yourprogram.deb
The true solution is... build from source.
But what if it's closed source?
Then reject it.
EDIT: I accidentally thought it was written on another thread.
If you use arch that isnt a problem
It's just maintaining arch that was a bit of a headache for me. I loved having access to the AUR and being able to use bleeding edge.. well, everything. But too much of my time ended up going to fixing issues after updates or finding out what package to choose when there were conflicts during updates.
endeavouros (based on arch, sway wm) is working great for me and I update it nearly every day
just run it through
alienand hopealready did once, it led me to an uninstallable package
Open it up in midnight commander, and it will unpack it into a virtual directory structure, complete with install/uninstall scripts.
Look at the install script to see what it's thinking, pull out the file structure, copy into your filesystem.
Oh, and hope. Because often you need to get matching glibc and other dynamic libraries that the program was compiled against. Which isn't the end of the world as the dynamic linker will look in the local directory where the program is first for libraries, but it becomes a hassle pretty quickly.
hence why I said hope
Llllllllllllllllllllllllllllollolllllllllllllllloooooooooooooiollllomkuuu'kj|mlll
No need to bring Icelandic volcanoes into this
I'll give you one more, what about software that doesn't package it at all and gives you a tar?
So what? You don't know how to unpack .deb?
Yehaa, a .deb file, letz install and just have fun
laughs in docker
@synae @nekothegamer there is something called distrobox which works alike https://github.com/89luca89/distrobox#installation
Check out Distrobox or Toolbox
i don't i use armcord most of the time
i'm pretty sure you can extract them with
ar xand get the binaryYou could also attempt converting them with alien or FPM
Alien
Distrobox, our hero
the struggle is real
Isn't deb just a compressed file? Can't you just decompress it, check its dependencies and install it yourself?
What could possibly go wrong with running precompiled binaries that were linked to a set of precompiled libraries with a completely different set of precompiled libraries.
You're not wrong, it's definitely not something a n00b should attempt in most cases. But I've done this before to save myself the need for distrobox. A lot of proprietary software only offers .deb, but is usually either statically linked or comes with its own set of nearly all the libraries it needs. So just extracting and running it often does the trick on non-debian distros like Fedora in my case.
Seriously though, just use distrobox or see if there's an unofficial package for your distro that you trust (AUR/copr/ppa/OBS). It's more straight forward especially if you don't know what you're doing.
Yup.
Nothing, lol. I have no issues running precompiled binaries on a fucking source-based distro.
I don't think the libraries would be in much different places but I think it would come down to the application and imprlementation
Not the locations. The versions. Your libssl-1.0 isn't the same as mine. There often are differences in major, minor or patch versions. There even are differences in compile options where a feature present in one is not compiled in another. E.g. ciphers available in libssl.
It is. Fancy tarball.
Try the VanillaOS 2.0 alpha?
https://handbook.vanillaos.org/2023/01/11/install-and-manage-applications.html
debtap exists
...for arch linux
With my finger on the trigger / I run dot slash configure / yo this package is big / but my package is bigger
me, who definitely knows how to and in fact totally prefers to build everything from source: [nervous laughter] yeah what kinda dingus exclusively uses .debs amirite?
That's not the point. It's about how you might be using a distro that isn't debian-based
ahem ahem discord
It is technically available as a tar.gz, but I'm not sure who they think is going to install that
Signal's shitty electron app.
Compile it from source?
Or:
Yeah I remember when Steam came to Linux. Never got it to work. I hope it is better nowadays? (Sadly can't check. My only pure Linux box at the moment is a Raspberry Pi, I don't expect Steam to run on that either)
Steam works fine for me. On Gentoo.
You can get Steam on just about any distro, for years at this point. And there's always Flatpak for these cases too although for Steam I recommend native packages.
?!? I'm not sure to understand this post? I will only install stuff that are .deb, not big image or snap or whatever?!?
What's the problem with deb when you are using debian based distro? Else you can easily extract the content and cp it in place
The meme is about running a non-Debian distro and finding only .deb installers.
Thx, captain.
Then treat is as tarball
but what about people that are not on debian or debian based distros... like me?
ding dong your distro is wrong
I will disclaim I’ve only used Debian based so I’m in no place to judge.
No offense, but debs are just objectively better than rpms. I use both
it doesn't matter which one is better, it's about compatibily, and there's no way to install .debs on, like, rpm based distros without getting completely broken uninstallable packages
Distrobox is the way. Running Fedora and I have debian and arch boxes (with their own home dir) installed. Graphical applications work without any fuss and I have yet to run into an issue.
Yes, that is why flatpak is a nice system