>No parallelism, no support for HTTP/2 and HTTP/3, etc.
You don't need that for downloading a file. It's pretty much useful for browsers only. If by parallelism you mean download-manager style multiple connections to download a bunch of files faster, I don't see how curl helps either, unless it has a feature I don't know about.
2 months ago
Anonymous
I mean the ability to fetch a list of URLs in parallel. Curl can fetch two or more files from multiple servers in parallel but Wget will wait for the first to finish downloading before starting the next, etc.
2 months ago
Anonymous
>No parallelism, no support for HTTP/2 and HTTP/3, etc.
You don't need that for downloading a file. It's pretty much useful for browsers only. If by parallelism you mean download-manager style multiple connections to download a bunch of files faster, I don't see how curl helps either, unless it has a feature I don't know about.
Also I disagree entirely that HTTP 2/3 are for browsers only. If you are doing any sort of scraping at all then you want HTTP 2 and 3 support precisely because that is what browsers support.
Curl can make itself look entirely like a web browser made the same request.
2 months ago
Anonymous
At least use Wget2. Wget is trash compared to curl. No parallelism, no support for HTTP/2 and HTTP/3, etc. Curl wins hands down.
what's the difference between >parallel | wget/curl
and >wget2
?
2 months ago
Anonymous
If you mean GNU Parallel then it spawns multiple processes, compared to Curl and Wget2 doing it internally with multiple threads which is more efficient.
2 months ago
Anonymous
how much more efficient when running locally and only parallelizing it to 5-10 downloads at a time? From what I've seen most websites don't let you exceed 5-10 and it's useless for LAN transfer too when, for example, I run python3 -m http.server on my phone.
2 months ago
Anonymous
[...]
what's the difference between >parallel | wget/curl
and >wget2
?
>passive aggressive lmgtfy
Are you at all capable of answering that? No? Then keep quiet.
2 months ago
Anonymous
Yeah I am. I'm the one who had to migrate web servers 10 years ago when it came out
2 months ago
Anonymous
We don't care about your life story, lady. Calm your passive aggressive breasts and post the answer, otherwise keep quiet.
2 months ago
Anonymous
You literally asked
You would have found the answer faster if you just googled it
2 months ago
Anonymous
>waah waaah give me attention I'm angry but I won't show it directly so I'll be passive aggressive instead!!!
No, autist. I asked you if you can answer a question. I didn't ask you about your irrelevant life story. Why do you sound like a woman? And one on her period at that.
2 months ago
Anonymous
Yeah sure I posted my answer here
https://letmegooglethat.com/?q=difference+between+http+1.1+and+http+2
2 months ago
Anonymous
Yes, lady. We know you're angry. No need for the "subtlety."
2 months ago
Anonymous
don't forget http2/3 protocol level parallelism as well
2 months ago
Anonymous
I can run wget 5 times to download 5 files in the time it takes to do curl settings to do 1 thing
2 months ago
Anonymous
Not if you're downloading 5 files from the same server you can't. That'll open and establish 5 separate connections with Wget. Curl will do pipe-lining properly.
There's a reason why so many software uses libcurl and nobody uses "libwget"
2 months ago
Anonymous
>There's a reason why so many software uses libcurl and nobody uses "libwget"
Which isn't the one you hinted at in your post.
I don't use Snap or Ubuntu for that matter so I don't need to cry. I was just explaining why they react that way. Nobody takes Ubuntu or Snaps seriously for any real work. It's okay on a server though.
Snap is so unbelievably bad. What a dogshit low IQ decision was to move firefox to snap by default. Every time you save a file or open the file upload window it freezes for a few seconds. It's beyond buggy and slow. I got flashbacks to my poorgay days when my main computer was a celeron acer laptop. And now my modern i9, 128 GB ram, nvme ssd computer is SLOWER than that thanks to fricking snap. have a nice day you incompetent trannies.
also the slow startup time
memory usage
and a shit ton of other bugs
I just don't get what the frick is the point of snap
did an actual group of non-moronic human beings decide to use this for some reason I can't comprehend?
also the slow startup time
memory usage
and a shit ton of other bugs
I just don't get what the frick is the point of snap
did an actual group of non-moronic human beings decide to use this for some reason I can't comprehend?
also the slow startup time
memory usage
and a shit ton of other bugs
I just don't get what the frick is the point of snap
did an actual group of non-moronic human beings decide to use this for some reason I can't comprehend?
[...]
thats what you get for supporting glibc morons
Snaps and Flatpaks were basically designed for two very different purposes. Ubuntu introduced Snaps to solve a very real problem in the server workspace, and that was the massive problem of trying to get newer software to work securely on older versions of Linux distributions that would be in the cloud. It's often difficult to upgrade the entire OS every six months or every two years on a production server, so many people stick on the LTS releases until the support period expires. Before Snaps came along, PPAs were the only way to really install newer versions of software, and that had a tendency to break things if you weren't careful.
Snaps came along in 2014 to solve this, and Snaps were extremely good at it too. Snaps are so powerful that you can literally make an entire Linux distribution in a Snap, which is something that Flatpaks simply cannot do. Snaps are very, very good at this, and Canonical designed them specifically to solve these kinds of problems (and they are ridiculously useful for IOT and server workspaces too).
The problem with Snaps is that the WEREN'T really initially designed with desktop apps in mind. Support for that came later, but Snaps didn't have the benefit of being made for this from the ground up. Flatpaks came about in 2015 (about a year after Snaps were introduced) and were designed to solve a much simpler problem. They were created to be great at applications, and as a result, they have a much simpler implementation that doesn't have to support the same depth of implementation. Flatpaks fundamentally work very differently, and install "runtimes" (which can be 1.3GB+ on the first install), which can be shared between Flatpaks once installed. Because of this, Flatpaks are typically huge on the first install but are fairly small afterwards, and don't have to rely on compression (which massively slowed down Snaps on launch).
To conclude, they're both good for the purposes they were designed for. Flatpaks are often a great choice for desktop apps because they launch quickly and can share runtimes, but sometimes Snaps provide a depth of containerization that is very useful for certain apps and provide a lot of low-level system functionality for things that need it. Flatpak is usually (not always) the simpler, more practical solution for most desktop apps, whereas Snap is the powerful workhorse that can do anything, but at a higher price. They're both wonderful things for the Linux community, but I do think Ubuntu probably should have offered both. Letting users pick the best tool for the job has always been the Linux way.
[...]
[...]
[...]
Snaps and Flatpaks were basically designed for two very different purposes. Ubuntu introduced Snaps to solve a very real problem in the server workspace, and that was the massive problem of trying to get newer software to work securely on older versions of Linux distributions that would be in the cloud. It's often difficult to upgrade the entire OS every six months or every two years on a production server, so many people stick on the LTS releases until the support period expires. Before Snaps came along, PPAs were the only way to really install newer versions of software, and that had a tendency to break things if you weren't careful.
Snaps came along in 2014 to solve this, and Snaps were extremely good at it too. Snaps are so powerful that you can literally make an entire Linux distribution in a Snap, which is something that Flatpaks simply cannot do. Snaps are very, very good at this, and Canonical designed them specifically to solve these kinds of problems (and they are ridiculously useful for IOT and server workspaces too).
The problem with Snaps is that the WEREN'T really initially designed with desktop apps in mind. Support for that came later, but Snaps didn't have the benefit of being made for this from the ground up. Flatpaks came about in 2015 (about a year after Snaps were introduced) and were designed to solve a much simpler problem. They were created to be great at applications, and as a result, they have a much simpler implementation that doesn't have to support the same depth of implementation. Flatpaks fundamentally work very differently, and install "runtimes" (which can be 1.3GB+ on the first install), which can be shared between Flatpaks once installed. Because of this, Flatpaks are typically huge on the first install but are fairly small afterwards, and don't have to rely on compression (which massively slowed down Snaps on launch).
thanks troonGPT
2 months ago
Anonymous
this clearly wasn't gpt you colossal homosexual
not everyone who posts long posts is a bot
also:
have a nice day
To conclude, they're both good for the purposes they were designed for. Flatpaks are often a great choice for desktop apps because they launch quickly and can share runtimes, but sometimes Snaps provide a depth of containerization that is very useful for certain apps and provide a lot of low-level system functionality for things that need it. Flatpak is usually (not always) the simpler, more practical solution for most desktop apps, whereas Snap is the powerful workhorse that can do anything, but at a higher price. They're both wonderful things for the Linux community, but I do think Ubuntu probably should have offered both. Letting users pick the best tool for the job has always been the Linux way.
(part 2/2)
I never even said anything about 'Flatpak' whatever that is and I don't give a shit about it, I'm talking about how parts of the software in the ubuntu repos take fricking forever to start and use lots of memory and don't use my GTK theme unless I manually copy it into every separate snap .themes folder and how my thunar window has a bunch of random "47MB volume" entries littering the devices section in the sidebar.
All that in addition to this stupid nagging message that asks me to close chromium which I keep doing and it keeps nagging me regardless.
Simply put the snap shit is just a fricking painful user experience
I see your point (I don't prefer them for desktop apps myself), but Snaps aren't cannibalizing regular .debs. These still exist and can be installed on any version of Ubuntu.
It's true that Canonical has replaced a small handful of .debs with Snaps (Firefox and Geany are the only two that I know of, and I'll agree that it's a bit ridiculous), but Ubuntu still inherits its package repositories from Debian and still maintains one of the largest package repositories in the entire Linux ecosystem. Neither Ubuntu nor Debian have any incentive to scale back their package repositories any time soon.
Flatpaks and Snaps are just tools. They are good for the use cases they were designed for, but the .Debs are still great and can still be installed. People often complain that the Debs are out of date, but this has always been the case and is the precise problem that Snaps and Flatpaks were created to solve.
>The problem with Snaps is that the WEREN'T really initially designed with desktop apps in mind
So same as wayland...
Why is nothing in the fricking linux desktop designed for desktop apps.
>Why is nothing in the fricking linux desktop designed for desktop apps.
the linux desktop is designed to provide a platform for macgays to develop software they don't use for users they hold in contempt.
you're not actually supposed to use it, it's just something that exists so that linuxgays can claim that they aren't FORCED to use the command line.
To conclude, they're both good for the purposes they were designed for. Flatpaks are often a great choice for desktop apps because they launch quickly and can share runtimes, but sometimes Snaps provide a depth of containerization that is very useful for certain apps and provide a lot of low-level system functionality for things that need it. Flatpak is usually (not always) the simpler, more practical solution for most desktop apps, whereas Snap is the powerful workhorse that can do anything, but at a higher price. They're both wonderful things for the Linux community, but I do think Ubuntu probably should have offered both. Letting users pick the best tool for the job has always been the Linux way.
(part 2/2)
Thank you for the explanation anon. I don't really like Snap either, but knowing such context is neat
thats interesting. Ive never had a problem with snaps on my ubuntu server and using it has actually been pretty good in that case
I use mint on my desktop so no snaps there
To conclude, they're both good for the purposes they were designed for. Flatpaks are often a great choice for desktop apps because they launch quickly and can share runtimes, but sometimes Snaps provide a depth of containerization that is very useful for certain apps and provide a lot of low-level system functionality for things that need it. Flatpak is usually (not always) the simpler, more practical solution for most desktop apps, whereas Snap is the powerful workhorse that can do anything, but at a higher price. They're both wonderful things for the Linux community, but I do think Ubuntu probably should have offered both. Letting users pick the best tool for the job has always been the Linux way.
The rest of this thread and the fact that the jannies never do absolutely anything about it is a good example of why it's not worth to write such posts on this dumpster
because they break shit with every release which forces everyone to recompile their software with every new release
this also sets a bad precedent and is just a shit experience
>because they break shit with every release which forces everyone to recompile their software with every new release
Examples? From what I know their policy is absolute compatibility.
The one potential problem is that when you build against a newer glibc, you can't run the binary with an older glibc.
2 months ago
Anonymous
>when you build against a newer glibc, you can't run the binary with an older glibc.
That means there's no compatibility lol
Also didn't you see what happened with the DT_GNU_HASH bullshit
2 months ago
Anonymous
>That means there's no compatibility lol
There is. You can run programs linked against older glibc on systems with newer glibc. Only the reverse isn't possible.
2 months ago
Anonymous
>their policy is absolute compatibility.
HAHAHAHAHAHAHAHAHAHAHAHA. Fricking lmao.
2 months ago
Anonymous
But that's the theory. They mess with complicated shit like symbol versioning to achieve it.
>How is glibc related?
That isnt a question you would ask if you'd ever tried to write a program for Linux that you wanted/needed to distribute to a ton of different operating systems.
>because they break shit with every release which forces everyone to recompile their software with every new release
Examples? From what I know their policy is absolute compatibility.
The one potential problem is that when you build against a newer glibc, you can't run the binary with an older glibc.
>The one potential problem is that when you build against a newer glibc, you can't run the binary with an older glibc.
Yea, so go try to see how pleasant it is when you need to develop a program where some of your important clients were still on CentOS 6 and Ubuntu 12.04 in 2022. >inb4 just do all your development on a 12 year old OS bro you don't need any modern tooling right? >what do you mean that version of gcc had severe bugs in the optimizer and produces substantially slower code? Deal with it!
also the slow startup time
memory usage
and a shit ton of other bugs
I just don't get what the frick is the point of snap
did an actual group of non-moronic human beings decide to use this for some reason I can't comprehend?
Snap is so unbelievably bad. What a dogshit low IQ decision was to move firefox to snap by default. Every time you save a file or open the file upload window it freezes for a few seconds. It's beyond buggy and slow. I got flashbacks to my poorgay days when my main computer was a celeron acer laptop. And now my modern i9, 128 GB ram, nvme ssd computer is SLOWER than that thanks to fricking snap. have a nice day you incompetent trannies.
also the slow startup time
memory usage
and a shit ton of other bugs
I just don't get what the frick is the point of snap
did an actual group of non-moronic human beings decide to use this for some reason I can't comprehend?
Non-Snap Firefox.
Even without addons, without history or cache, without custom settings and with several windows to open; Snap Firefox takes about 2 seconds longer to open on 2018 hardware.
Even without addons, without history or cache, without custom settings and with several windows to open; Snap Firefox takes about 2 seconds longer to open on 2018 hardware.
The difference is truly meaningless.
The problem is not Firefox, it's the DE. I switched to xfce and not it opens pretty much instantly.
>no linux trannies are not moronic and incompetent! you are just using the wrong linux troony package! you have to use something made by a different group of linux trannies!
2 months ago
Anonymous
No point in throwing a fit when you don't even know what a DE is.
Snaps are still a real pain if you have HOME on automounted NFS, if HOME is not under /home/ or if there is s symlink in your HOME path, which are all very common on many university and enterprise desktop deployments. The snap designers were simply unfamiliar with such environments. AppArmor limitations (not being able to distinguish direct network access from indirect network access via mounted networked file systems) is another problem area for many snaps trying to restrict network access.
>HOME on automounted NFS,
GOD I HATE THIS SETUP SO FRICKING MUCH >oh nice you want to use a nice little shell that stores your history in a DB instead of raw text? >well frick you, have some slowdowns
>"just switch to lin-ACKCKCKKKCKKKKK" >tries to grab at throat as the rope tightens >sounds of ceiling fan squeaking as the soon-to-be corpse flails around >pisses and shits self >face turns purple and eyes roll back in head >brainless twitching as brain runs out of oxygen
No thanks
>decide to try latest Release Candidate of any mainstream linux distro >The RC already is behind in software versions, even before GA release >muh stability (contains 2+ year old bugs that make your life miserable)
it's like rolling release but overengineered
for desktops, the point-release model for operating systems became obsolete with the advent of cheap internet
>the point-release model for operating systems became obsolete with the advent of cheap internet
Stable and reliable operating systems became obsolete with the advent of cheap internet? That doesn't make sense
Ubuntu is based on debian, and debian want to be stable, while ubuntu want to explore many different path.
Snap was the best idea to have bot, stability and possibility of change and risk without much risks.
Why not? Curl actually improves between versions, for one, they added curling to .socket files around 2021.
you can use wget for that
At least use Wget2. Wget is trash compared to curl. No parallelism, no support for HTTP/2 and HTTP/3, etc. Curl wins hands down.
>No parallelism, no support for HTTP/2 and HTTP/3, etc.
You don't need that for downloading a file. It's pretty much useful for browsers only. If by parallelism you mean download-manager style multiple connections to download a bunch of files faster, I don't see how curl helps either, unless it has a feature I don't know about.
I mean the ability to fetch a list of URLs in parallel. Curl can fetch two or more files from multiple servers in parallel but Wget will wait for the first to finish downloading before starting the next, etc.
Also I disagree entirely that HTTP 2/3 are for browsers only. If you are doing any sort of scraping at all then you want HTTP 2 and 3 support precisely because that is what browsers support.
Curl can make itself look entirely like a web browser made the same request.
what's the difference between
>parallel | wget/curl
and
>wget2
?
If you mean GNU Parallel then it spawns multiple processes, compared to Curl and Wget2 doing it internally with multiple threads which is more efficient.
how much more efficient when running locally and only parallelizing it to 5-10 downloads at a time? From what I've seen most websites don't let you exceed 5-10 and it's useless for LAN transfer too when, for example, I run python3 -m http.server on my phone.
https://letmegooglethat.com/?q=difference+between+http+1.1+and+http+2
>passive aggressive lmgtfy
Are you at all capable of answering that? No? Then keep quiet.
Yeah I am. I'm the one who had to migrate web servers 10 years ago when it came out
We don't care about your life story, lady. Calm your passive aggressive breasts and post the answer, otherwise keep quiet.
You literally asked
You would have found the answer faster if you just googled it
>waah waaah give me attention I'm angry but I won't show it directly so I'll be passive aggressive instead!!!
No, autist. I asked you if you can answer a question. I didn't ask you about your irrelevant life story. Why do you sound like a woman? And one on her period at that.
Yeah sure I posted my answer here
https://letmegooglethat.com/?q=difference+between+http+1.1+and+http+2
Yes, lady. We know you're angry. No need for the "subtlety."
don't forget http2/3 protocol level parallelism as well
I can run wget 5 times to download 5 files in the time it takes to do curl settings to do 1 thing
Not if you're downloading 5 files from the same server you can't. That'll open and establish 5 separate connections with Wget. Curl will do pipe-lining properly.
There's a reason why so many software uses libcurl and nobody uses "libwget"
>There's a reason why so many software uses libcurl and nobody uses "libwget"
Which isn't the one you hinted at in your post.
>snap
>8.1.2
>apt
>7.81.0
HAHAHAHAHAHAHAHAHHAHAHAHAHAHAHHA I HATE FREETARDS SO FRICKING MUCH
Canonical is moronic
braindead Black folk who have never even heard of LTS
The Snap is still outdated
cry about it. literally not my problem
I don't use Snap or Ubuntu for that matter so I don't need to cry. I was just explaining why they react that way. Nobody takes Ubuntu or Snaps seriously for any real work. It's okay on a server though.
These are the same troons saying
>i dont use windows, its bloated
These the same troons that use gayland and rust
Snap is so unbelievably bad. What a dogshit low IQ decision was to move firefox to snap by default. Every time you save a file or open the file upload window it freezes for a few seconds. It's beyond buggy and slow. I got flashbacks to my poorgay days when my main computer was a celeron acer laptop. And now my modern i9, 128 GB ram, nvme ssd computer is SLOWER than that thanks to fricking snap. have a nice day you incompetent trannies.
also the slow startup time
memory usage
and a shit ton of other bugs
I just don't get what the frick is the point of snap
did an actual group of non-moronic human beings decide to use this for some reason I can't comprehend?
everything you mentioned are issues that were relevant more than 2 years ago...
I run snap firefox on my old ass x230 and I dont have a single problem
>random internet loser moron is trying to gaslight me about my personal experience
No, moron, I'm pretty sure I can trust my memory and eyes.
your personal experience doesn't matter if you are a midwit
You are an abject moron and you know it. No matter how hard you seethe on IQfy you'll still be a complete failure IRL.
you're the only one seething here, stop projecting
Wrong answer.
thats what you get for supporting glibc morons
Nani, the frick?
USE THE SOURCE, LUKE.
Snaps and Flatpaks were basically designed for two very different purposes. Ubuntu introduced Snaps to solve a very real problem in the server workspace, and that was the massive problem of trying to get newer software to work securely on older versions of Linux distributions that would be in the cloud. It's often difficult to upgrade the entire OS every six months or every two years on a production server, so many people stick on the LTS releases until the support period expires. Before Snaps came along, PPAs were the only way to really install newer versions of software, and that had a tendency to break things if you weren't careful.
Snaps came along in 2014 to solve this, and Snaps were extremely good at it too. Snaps are so powerful that you can literally make an entire Linux distribution in a Snap, which is something that Flatpaks simply cannot do. Snaps are very, very good at this, and Canonical designed them specifically to solve these kinds of problems (and they are ridiculously useful for IOT and server workspaces too).
The problem with Snaps is that the WEREN'T really initially designed with desktop apps in mind. Support for that came later, but Snaps didn't have the benefit of being made for this from the ground up. Flatpaks came about in 2015 (about a year after Snaps were introduced) and were designed to solve a much simpler problem. They were created to be great at applications, and as a result, they have a much simpler implementation that doesn't have to support the same depth of implementation. Flatpaks fundamentally work very differently, and install "runtimes" (which can be 1.3GB+ on the first install), which can be shared between Flatpaks once installed. Because of this, Flatpaks are typically huge on the first install but are fairly small afterwards, and don't have to rely on compression (which massively slowed down Snaps on launch).
To conclude, they're both good for the purposes they were designed for. Flatpaks are often a great choice for desktop apps because they launch quickly and can share runtimes, but sometimes Snaps provide a depth of containerization that is very useful for certain apps and provide a lot of low-level system functionality for things that need it. Flatpak is usually (not always) the simpler, more practical solution for most desktop apps, whereas Snap is the powerful workhorse that can do anything, but at a higher price. They're both wonderful things for the Linux community, but I do think Ubuntu probably should have offered both. Letting users pick the best tool for the job has always been the Linux way.
(part 2/2)
thanks troonGPT
this clearly wasn't gpt you colossal homosexual
not everyone who posts long posts is a bot
also:
have a nice day
I never even said anything about 'Flatpak' whatever that is and I don't give a shit about it, I'm talking about how parts of the software in the ubuntu repos take fricking forever to start and use lots of memory and don't use my GTK theme unless I manually copy it into every separate snap .themes folder and how my thunar window has a bunch of random "47MB volume" entries littering the devices section in the sidebar.
All that in addition to this stupid nagging message that asks me to close chromium which I keep doing and it keeps nagging me regardless.
Simply put the snap shit is just a fricking painful user experience
I see your point (I don't prefer them for desktop apps myself), but Snaps aren't cannibalizing regular .debs. These still exist and can be installed on any version of Ubuntu.
It's true that Canonical has replaced a small handful of .debs with Snaps (Firefox and Geany are the only two that I know of, and I'll agree that it's a bit ridiculous), but Ubuntu still inherits its package repositories from Debian and still maintains one of the largest package repositories in the entire Linux ecosystem. Neither Ubuntu nor Debian have any incentive to scale back their package repositories any time soon.
Flatpaks and Snaps are just tools. They are good for the use cases they were designed for, but the .Debs are still great and can still be installed. People often complain that the Debs are out of date, but this has always been the case and is the precise problem that Snaps and Flatpaks were created to solve.
>The problem with Snaps is that the WEREN'T really initially designed with desktop apps in mind
So same as wayland...
Why is nothing in the fricking linux desktop designed for desktop apps.
because botched is the true unix philosophy
>Why is nothing in the fricking linux desktop designed for desktop apps.
the linux desktop is designed to provide a platform for macgays to develop software they don't use for users they hold in contempt.
you're not actually supposed to use it, it's just something that exists so that linuxgays can claim that they aren't FORCED to use the command line.
Thank you for the explanation anon. I don't really like Snap either, but knowing such context is neat
Appimages are superior
thats interesting. Ive never had a problem with snaps on my ubuntu server and using it has actually been pretty good in that case
I use mint on my desktop so no snaps there
High quality posts on IQfy, who would've thought
The rest of this thread and the fact that the jannies never do absolutely anything about it is a good example of why it's not worth to write such posts on this dumpster
>Snaps are so powerful that you can literally make an entire Linux distribution in a Snap
I don't quite understand this part, could you clarify it?
Snaps are great
Doesn't happen on my machine. 5800X, 32GB RAM and a 6600XT
i don't even use packages for firefox, i just download the binary from the firefox website every time i want to update
If you're honest you'll realize everything about Linux is low IQ. They are just hobbyists making do with the few braincells they were born with.
Why is it slow?
How is glibc related?
because they break shit with every release which forces everyone to recompile their software with every new release
this also sets a bad precedent and is just a shit experience
>because they break shit with every release which forces everyone to recompile their software with every new release
Examples? From what I know their policy is absolute compatibility.
The one potential problem is that when you build against a newer glibc, you can't run the binary with an older glibc.
>when you build against a newer glibc, you can't run the binary with an older glibc.
That means there's no compatibility lol
Also didn't you see what happened with the DT_GNU_HASH bullshit
>That means there's no compatibility lol
There is. You can run programs linked against older glibc on systems with newer glibc. Only the reverse isn't possible.
>their policy is absolute compatibility.
HAHAHAHAHAHAHAHAHAHAHAHA. Fricking lmao.
But that's the theory. They mess with complicated shit like symbol versioning to achieve it.
>How is glibc related?
That isnt a question you would ask if you'd ever tried to write a program for Linux that you wanted/needed to distribute to a ton of different operating systems.
>The one potential problem is that when you build against a newer glibc, you can't run the binary with an older glibc.
Yea, so go try to see how pleasant it is when you need to develop a program where some of your important clients were still on CentOS 6 and Ubuntu 12.04 in 2022.
>inb4 just do all your development on a 12 year old OS bro you don't need any modern tooling right?
>what do you mean that version of gcc had severe bugs in the optimizer and produces substantially slower code? Deal with it!
Snap Firefox.
Non-Snap Firefox.
Even without addons, without history or cache, without custom settings and with several windows to open; Snap Firefox takes about 2 seconds longer to open on 2018 hardware.
The difference is truly meaningless.
The problem is not Firefox, it's the DE. I switched to xfce and not it opens pretty much instantly.
>no linux trannies are not moronic and incompetent! you are just using the wrong linux troony package! you have to use something made by a different group of linux trannies!
No point in throwing a fit when you don't even know what a DE is.
Snaps are still a real pain if you have HOME on automounted NFS, if HOME is not under /home/ or if there is s symlink in your HOME path, which are all very common on many university and enterprise desktop deployments. The snap designers were simply unfamiliar with such environments. AppArmor limitations (not being able to distinguish direct network access from indirect network access via mounted networked file systems) is another problem area for many snaps trying to restrict network access.
>HOME on automounted NFS,
GOD I HATE THIS SETUP SO FRICKING MUCH
>oh nice you want to use a nice little shell that stores your history in a DB instead of raw text?
>well frick you, have some slowdowns
The solution is Plan 9, but you IT guys are too moronic to see that.
JUST
FRICKING
INSTALL
A
STATIC
BINARY
>installs two year old version that has bugs because "stability"
Holy kys
https://github.com/stunnel/static-curl
okay package janny
Ubuntu would be a competent distro if it weren't for snap.
>"just switch to lin-ACKCKCKKKCKKKKK"
>tries to grab at throat as the rope tightens
>sounds of ceiling fan squeaking as the soon-to-be corpse flails around
>pisses and shits self
>face turns purple and eyes roll back in head
>brainless twitching as brain runs out of oxygen
No thanks
>face turns purple and eyes roll back in head
>brainless twitching as brain runs out of oxygen
sauce
>decide to try latest Release Candidate of any mainstream linux distro
>The RC already is behind in software versions, even before GA release
>muh stability (contains 2+ year old bugs that make your life miserable)
such is life of freetards
>Windows user who tinker trannies to disable updates complaining about old software
Like clockwork
>I make up shit in my imagination to try to make my failure of an operating system not look like trannie bait
every time
>he lets a company decide when his computer reboots
it's like rolling release but overengineered
for desktops, the point-release model for operating systems became obsolete with the advent of cheap internet
>the point-release model for operating systems became obsolete with the advent of cheap internet
Stable and reliable operating systems became obsolete with the advent of cheap internet? That doesn't make sense
Ubuntu is based on debian, and debian want to be stable, while ubuntu want to explore many different path.
Snap was the best idea to have bot, stability and possibility of change and risk without much risks.
snap works fine, it has never given me a problem, so i don't care
>UNIX philosophy
Should Linux follow the Windows philosophy to improve?
yes
praise lennart
How do I open SystemD GUI?
Why does their Github not have exe?
same for qbittorrent and web browsers as well
anyone wanna translate what this means to non-freetardian? why does that matter?
If you curl your dick too hard it snaps off.
Ubuntu is dead.
snap killed it.
>Ubuntu is dead.
>snap killed it.
this.
once snap is mandatory (CUPS as snap in 24.10) I'm switching to Debian or Mint DE.
frick you, Canonical.
not my problem
It's also available as a Docker container by the way:
https://hub.docker.com/r/curlimages/curl
what the FRICK
snap is fine on servers
If you use flats or snaps you are hereby excommunicated from Linux community