There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

programmer_belch ,
@programmer_belch@lemmy.dbzer0.com avatar

Just compile from source?

Norgur ,
@Norgur@fedia.io avatar

Back in the day, when I installed my very first Linux OS, I had a wireless stick from Netgear. Wireless Drivers back then were abysmal, so I had to compile them from source (literally 15 mins after seeing a TTY for the first time). After I had found out how build-dependencies and such worked somehow and ./configure completed successfully for the first time, the script ended with the epic line:

configure done. Now type 'make' and pray

ace ,
@ace@lemmy.ananace.dev avatar

Ah, I had one of those wireless sticks from Netgear as well, probably a different model but still a royal pain to get it working.
Luckily ndiswrapper has become a thing of the past nowadays.

possiblylinux127 ,

Not optimal

programmer_belch ,
@programmer_belch@lemmy.dbzer0.com avatar

Yes, it would depend on your flatpack usage. For me I only have like 5 programs compiled from source and one flatpack (bottles) because of the sandboxing

possiblylinux127 ,

That’s not good. It breaks the system as there isn’t any change control with that unless your using something like Gentoo. Get your packages from the package manager.

programmer_belch ,
@programmer_belch@lemmy.dbzer0.com avatar

None of the packages I compile from source are essential to my working system. I have a private chatbot to test, some emulators and dsda-doom.

Every one of those programs can be one or two versions obsolete and it won’t make a difference.

Zacryon ,

Because it’s always so easy to compile everything you need from source! Just make sure to download, compile and install the dependencies first as well. Oh, and the dependencies’ dependencies. And the ones from them. And so on. Unless you’re lucky enough that there are already packaged dependencies available for you. Don’t know how to compile? No problem, just read the documentation. You can be absolutely 1000000% dead serious sure that everything you need to know is documented and extremely super duper easy to understand if you don’t know the source code or barely know how to code at all. And if not, maybe you can find the bits of information on the respective Discord server. It will probably be also very intuitive to know which build options you have to set in which way and which ones even exist. And that without causing conflicts with other packages you need to compile. Still got got problems with compiling? EZ, just open a bunch of issues on the respective GitHub pages. (If present. Otherwise, try to find another way to contact devs and get support, Discord for example.) Maybe, about six months later you’re lucky to get a response. And if not, don’t worry. Some will tell you, you should RTFM or are an idiot. Some will just close the issue because your platform isn’t supported anyway. Then you know, what you did wrong. Also don’t mind if your issue gets ignored.
If you finally managed to compile everything from source, congratulations! Now run the program and test if everything is working. If it’s not or if it is crashing, don’t worry! In developed and civilised countries you can just buy a shotgun and blast your own head away to end this suffering.

EZ! Just compile from source!

programmer_belch ,
@programmer_belch@lemmy.dbzer0.com avatar

I just complie from source some lightweight programs that are too niche for repositories. I am in no way advocating for full source compilation of every program in your system, that’s a security and usage nightmare. Flatpack does have its use for sandboxing an environment. I personally use it for windows applications in bottles.

henfredemars ,

My workflow always definitely includes multiple weeks to debug random issues with building the tools I need to use. Totally a scalable and good solution to dump this work on the end user.

uis ,

You have rediscovered LFS

henfredemars ,

This doesn’t scale. If I have a bug and my package has about two dozen dependencies which can all be different versions, and the developer can’t reproduce my bug, I’m just screwed. Developers don’t have the time and resources to chase down a bug that depends on build time variables.

Ask me how I know this happens.

superminerJG ,

And this, this is why I love the AUR

corsicanguppy , (edited )

I think no one said it needs to be ON a distro’s repos. That’s a straw man.

A package should be available in a native package format in a way that doesn’t cause conflict with what’s in the official repo. The reasons for a single source of truth on installed status should be obvious; but given the format of some packaging and the signed assurance of provenance, thr advantages to a native format can be leaves ahead of even that.

Wow, is this meme a really naive take that is contradicted by - oh god, everything. Can someone know about enterprise Linux and also be this naive?

kuberoot ,

The responsibility to figure out the dependencies and packaging for distros, and then maintain those going forwards, should not be placed on the developer. If a developer wants to do that, then that’s fine - but if a developer just wants to provide source with solid build instructions, and then provide a flatpak, maybe an appimage, then that’s also perfectly fine.

In a sense, developers shouldn’t even be trusted to manage packaging for distributions - it’s usually not their area of expertise, maintainers of specific distributions will usually know better.

raspberriesareyummy ,

While I agree that developers (like myself) are not necessarily experts at packaging stuff, to conclude that it’s fine that a developer provides a flatpak is promoting shitty software. Whether a software should run in a jail, or within user space is a decision that - for most use cases - should be made by the user.

There is absolutely no reason not to provide software as a tar.gz source code archive with a proper makefile & documentation of dependencies - or automake configuration if that’s preferred.

From that kind of delivery, any package maintainer can easily build a distro-package.

kuberoot ,

I think you’re actually agreeing with me here. I was disputing the claim that software should be made available in “a native package format”, and my counterpoint is that devs shouldn’t be packaging things for distros, and instead providing source code with build instructions, alongside whatever builds they can comfortably provide - primarily flatpak and appimage, in my example.

I don’t use flatpak, and I prefer to use packages with my distro’s package manager, but I definitely can’t expect every package to be available in that format. Flatpak and appimage, to my knowledge, are designed to be distro-agnostic and easily distributed by the software developer, so they’re probably the best options - flatpak better for long-term use, appimage usable for quickly trying out software or one-off utilities.

As for tar.gz, these days software tends to be made available on GitHub and similar platforms, where you can fetch the source from git by commit, and releases also have autogenerated source downloads. Makefiles/automake isn’t a reasonable expectation these days, with a plethora of languages and build toolchains, but good, clear instructions are definitely something to include.

raspberriesareyummy ,

Makefiles/automake isn’t a reasonable expectation these days, with a plethora of languages and build toolchains, but good, clear instructions are definitely something to include.

As for the Makefiles, I meant that for whatever build toolchain the project uses - because the rules to build a project are an essential part of the project, linking the source code into a working library or executable. Whether it is cmake, or gnu make, or whatever else there is - that’s not so important as long as those build toolchains are available cross platforms.

I think what is really missing in the open source world is a distribution-agnostic standard how to describe application dependencies so that package maintainers can auto-generate distro-packages with the distribution-specific dependencies based on that “dependencies” file.

Similar to debian dependencies Depends: libstdc++6 (>= 10.2.1)but in a way that identifies code modules, not packages, so that distributions that package software together differently will still be able to identy findPackageFor( dependency )

I would really like to add this kind of info to my projects and have a tool that can auto-build a repo-package from those.

rozodru ,

“oh this is a flatpak or hell even a windows exe…” proceeds to search for it on AUR “ah there it is, wonderful!”

Hell I’ve found a god damn windows gaming cheat trainer on AUR and it worked.

lemmyvore ,

The AUR is basically just a script that describes best case scenario for building something under Arch. They don’t have any specific quality rules they have to meet.

It’s super easy to make and publish an AUR script compared to a regular distro package (including Arch packages).

superminerJG ,

Usually they work well enough, especially things that just involve repacking binaries (e.g. printer drivers)

amw3i7dwgoblinlabs ,
@amw3i7dwgoblinlabs@lemmy.world avatar

False, if it exists in the Linux ecosystem it also exists in AUR

wuphysics87 ,

The broader meta point is that X thing you want isn’t the devs job, btw.

SpaceCadet ,
@SpaceCadet@feddit.nl avatar

X thing you want isn’t the devs job

Well, it is if they decide it is, and it isn’t if they decide it isn’t.

That said, I do appreciate devs who put up native deb or rpm repos for the most common distros.

uis , (edited )

Meanwhile almost everything I ever wanted is either in main Gentoo repo or in there is overlay with it.

Illecors ,

Honestly, main + guru has not made feel like anything’s missing at all.

uis ,

Main + kdab + steam

Ephera ,

I am inclined to write “Main +” and then just some random words, to see if you guys could tell they’re not repos. 🙃

uis ,

Guru is Project:GURU, kdab is KDAB overlay for hotspot profiler and steam is steam-overlay

Ephera ,

Sure, but through your link, I found the list of projects. In hopes that a project always has a repo associated, here comes the quiz: Can you guess which 2 of these projects I made up? 🙃

Main + Artwork + Astronomy + Biology + Chemistry + Electronics + Geosciences + Mathematics + Physics + Psychology + Science + Retirement + Emacs + GNU Emacs + Spacemacs + XEmacs

I did expect there to be lots of random words, but man, I seriously had to think for a moment to find a field of science that isn’t covered…

uis ,

I seriously had to think for a moment to find a field of science that isn’t covered…

And you choose phsycology… Medicine would be less obvious.

For my second guess I was choosing between retirement and spacemacs. As it turns out, Project:Retirement is a thing.

Also Project:Main doesn’t exist. So you made up 3 projects.

That list I and person I replied to posted was list of overlays.

Ephera ,

Welp. I didn’t want to make it too difficult either, especially with how funky some of the real projects are. Would be cool, though, if more psychology software existed. Surely, there’s a lot you could do with video games / simulations.

Ephera ,

I just distribute it as a self-contained executable/archive. ¯_(ツ)_/¯

ms_lane ,

AppImage for the win!

RmDebArc_5 ,
@RmDebArc_5@sh.itjust.works avatar

Valid solution, but I miss unified updates with appimages and such

Ephera ,

Yeah, that’s the fun part. Hooking into some auto-update mechanism would be useful to me.

But my stuff is mostly in the scratching-my-own-itch stage, so setting up a FlatHub account, Flatpak metadata, sandbox rules, probably an icon and screenshots and whatnot, and automating the build+releases, just to get auto-updates, yeah… no.

I could code a whole nother project in the time that would take.

ace ,
@ace@lemmy.ananace.dev avatar

Well, if you have any form of build script, makefile, or CI, then you can easily shove that into a flatpak-builder manifest and push the build repo anywhere you want. The default OSTree repository format can be served from any old webserver or S3 bucket after all.

I’ve done this for personal projects many times, since it’s a ridiculously easy way to get scalable distribution and automatic updates in place.

Ephera ,

Hmm, okay, that doesn’t sound too bad.
Does the sandboxing get into the way much? Can a user tell it to poke a hole into the sandbox, to use some specific folder, for example?

I think, my real problem is that I don’t actually use Flatpak for any software I have installed. 😅
I’m not opposed to using Flatpak, but I disabled Flathub pretty quickly on my distro’s software store thingamabob, when I accidentally installed some proprietary software from it. Fuck that shit, no matter how much sandboxing I get.

ace ,
@ace@lemmy.ananace.dev avatar

In regards to sandboxing, it only gets as far in the way as you ask it to. For applications that you’re not planning on putting on FlatHub anyway you can be just as open as you want to be, i.e. just adding / - or host as it’s called - as read-write to the app. (OpenMW still does that as we had some issues with the data extraction for original Morrowind install media)

If you do want to sandbox though, users are able to poke just as many holes as they want - or add their own restrictions atop whatever sandboxing you set up for the application. Flatpak itself has the flatpak override tool for this, or there’s graphical UIs like flatseal and the KDE control center module…

ace ,
@ace@lemmy.ananace.dev avatar

As long as your application is statically linked, I don’t see any issue with that.

Ephera ,

So, like, dumb question. People here assumed that I mean AppImages, whereas I actually meant just a statically linked binary. Is that really the only reason why AppImage exists? So, that dynamically linked applications can be distributed like statically linked ones?

ryannathans ,

You cannot statically link everything. Take graphics libraries and APIs for example, do you statically link against nvidia’s or mesa’s opengl?

ryannathans ,

You cannot statically link everything. Take graphics libraries and APIs for example, do you statically link against nvidia’s or mesa’s opengl?

Ephera ,

Sure, but presumably AppImage/Flatpak/Docker cannot help with that either…?

henfredemars ,

This is the problem those tools try to solve. They package everything else upon which software might depend that can’t simply be linked into a single binary.

ryannathans ,

Flatpak solves the problem with targetable platform versions, you just update the manifest for your app every like 6-12 months to target the new one

Ephera ,

Ah, interesting. So, it’s different from just statically linking against the latest driver lib every 6-12 months, because the Flatpak runtime gives you a bit of a guarantee that there won’t be breaking changes in the meantime.

ryannathans ,

Bingo, and if the latest mesa breaks your app for example, you can target an older one until it’s fixed instead of end users having to fuck around downgrading system packages

ace ,
@ace@lemmy.ananace.dev avatar

The majority of AppImages I’ve seen have been dynamically linked, yes. But it’s also used for packaging assets.

Ephera ,

Yeah, alright, packaging assets makes sense. I’ve always been fine with just a .tar.gz, but having it be a singular file without compression is cool.

I guess, since AppImage emulates a filesystem, you can also have your application logic load the assets from the same path as if the assets were installed on the OS, so that’s also cool.

bruhduh ,
@bruhduh@lemmy.world avatar

openbuildservice.org

iopq ,

Nix: you package it yourself and do a pull request

Sadly, many flatpaks don’t even work on NixOS properly because of assumptions about the file structure or similar

starman ,
@starman@programming.dev avatar

Exactly. And even if one doesn’t know how to package it, they can just open a request issue.

rickyrigatoni ,

People always forget about appimages.

fruitycoder ,

As they should /s

Honestly its neat but I don’t see why I would want it over flatpak ever

azenyr ,

Same app in native format: 2MB. As a flatpak: 15MB. As an appimage: 350MB.

Appimages are awesome, rock solid, and I have a few on my system, but flatpak never gave me any problem and integrates better with my KDE, and is smaller. Both have their advantages tho. I’m fine with using both. If you are a developer, make a flatpak or an appimage i dont really care just make your software available for linux. Both are fine, choose the one that fits your specific app the most.

But I also think appimages deserve the same attention and great integration with the OS as flatpaks. Stuff like that AppImageLauncher functionalities should just be integrated inside the DE itself.

But we need an universal package format for linux asap. Flatpak is on the front in this race, and I’m fine with it. Appimages second, for sure.

rickyrigatoni ,

If you don’t run your install off a 12 zetabyte NAS are you even a real linux user?

corsicanguppy ,

Your security people have not forgotten about appimages. It fills their nightmares.

Wofls ,

I don’t wanna be that guy, but someone has to say it: Nix Flakes

renzev OP ,

I have both nix and flatpak lol. Different usecases: flatpak for stuff that I would rather have sandboxed (browsers, games), nix for stuff that I would rather be integrated into the system (command line tools, etc). Tho I still have to learn about flakes, right now I’m just using nix-env for everything like a caveman lol

Skyflare ,

Bottle’s developers disagree with this meme

tiziodcaio ,

I cannot use bottles since months due to their faltpak monogamy policy :/

OsrsNeedsF2P ,

…explain? It literally has Flatpak as first-class support, i.e. it’s guaranteed and only guaranteed to work on Flatpak

tiziodcaio ,

Because I use it from the AUR…

OsrsNeedsF2P ,

Try using the Flatpak

jj4211 ,

You don’t need the distro to package your sodtware through their package management systems though. Apt and dnf repositories are extensible, anyone can publish. If you go to copr or ppa you can have a little extra help too, without distro maintainers.

The headache comes up when multiple third party repositories start conflicting with each other when you add enough of them, despite they’re best efforts. This scenario starts needing flatpack, which can, for example concurrently provide multiple distinct library versions installed that traditionally would conflict with each other. This doesn’t mean application has to bundle the dependency, that dependency can still be external to the package and independently updated, it just means conflicts can be gracefully handled.

breakingcups ,

The headache comes up when multiple third party repositories start conflicting with each other

Which is traditionally why you needed the distro to package your software…

jj4211 ,

Depends on if you stick to distro provided dependencies, then you are generally good, unless a third party repo decided to supersede that dependency.

I have spent a long time carefully packaging as a third party repository and it’s generally doable. Just sometimes another repository isn’t as careful and blows away the distribution provided libraries.

Liz ,

I know nothing about how flatpak works other than that it’s containerized. But this meme tells me it’s the OS’s responsibility to create the flatpak, and not the developer’s? Is that right?

fruitycoder ,

No the most common way is for devs to package their own software as a flatpak since you can typically choose your preferred packaging tool to use inside of the flatpak.

Traditional package management typically is done by the distro maintainers.

Liz ,

Oh I see, I’ve got it backwards.

user ,

flatkill.org

renzev OP ,

that website is such a joke, I can’t believe the guy’s still paying for the domain name… The whole argument boils down to “Many flatpak apps don’t make use of the sandbox by default, which is <somehow> less secure than not having a sandbox at all” and “this one app I like doesn’t work in flatpak, therefore all of it is bad”.

…unless it literally is a joke and I’m just missing out on the sarcasm?

user ,

Its only worse than not having it at all in the sense of giving users a false sense of security. Imagine if apps on mobile could decide what permissions they want automatically granted without the user opting in. The sandbox HAS to be enforced by default to be good. And the other issue with flatpak is the security, which we had several problems with in the past. On the same note, people criticise snap but its a much more competent solution from a technical standpoint regarding security and since people get all their apps from flathub anyways, the “propreitary” backend is mostly irrelevant. And before anyone says “snap store had malware hosted” that is not an issue with the format itself but the infrastructure.

user ,

Also. Maintaining snap packages are easier for developers, and companies, therefore they are more likely to distribute apps on Linux to begin with.

renzev OP ,

Its only worse than not having it at all in the sense of giving users a false sense of security.

Flathub’s website has a bigass banner telling you if an app requires permissions that they consider dangerous. And flatpak’s CLI tells you what permissions are needed when installing an app. It’s pretty hard to miss, no?

https://lemmy.world/pictrs/image/41c2ec76-8e15-484a-a8db-b2ac1631d83b.pnghttps://lemmy.world/pictrs/image/a722fb11-562b-4c93-8ba1-3df375bca071.png

user ,

This is still not a reason to automatically grant them. This permission model is fundamentally flawed. Besides, the CLI doesn’t even show these.

Itdidnttrickledown ,

I’ve never used it. Its like all the others though and I have been forced to use snaps. Those I slowly replace every time I decide to start fresh.

renzev OP ,

Try linux mint, it’s basically ubuntu but without snap (you can install snap if you want to, but it’s not forced on you)

Itdidnttrickledown ,

Oh I have. I have it running on some older hardware.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • random
  • [email protected]
  • lifeLocal
  • goranko
  • All magazines
    •