Don't you wish linux or windows installed programs this easy?

This, fuck proprietary software

>he says as he posts that to Jow Forums, a proprietary imageboard
retard

Linux has the easiest installation method, literally one click + password prompt.

>we should improve society somewhat
>yet you participate in society, curious
>i am very intelligent

But static linking is good, fuck dynamic linking meme, you still need multiple versions because this trash conflicts all the time. It also spawned such abominations as containers simply to make this shit behave like static linking.

>implying Jow Forums doesn't suck

We got a bootcamp app dev here guys.
Buckle up.

>shitnux

i never use dragging so it would be shitty and counter intuitive

>We got a bootcamp app dev here guys.
>Buckle up.

Nah, I'm with that guy. Eliminate unnecessary dependencies and include everything you need with the app itself.

Attached: hj4lo2hh5tv11.jpg (800x1200, 122K)

Many Mac applications are universal binaries. Older ones containing both PowerPC and x86 binaries and newer ones containing IA32 and x86_64 binaries

Linux does

Attached: appImage-linux-720x340.png (720x340, 290K)

>sudo apt install program name
Could it be any easier?

Not to mention that what you execute as a program is actually a directory. Think of it like if directories in C:\Program Files in Windows executed the binary within when the directory's double clicked

Attached: Screen Shot 2018-11-02 at 13.37.47.png (955x583, 114K)

This. Dynamic linking has never worked right going all the way back to the fucking 90's. It's an idea that sounds GREAT on paper but turns to shit in the real world.

People use apps, not libraries. So an app should have everything it needs.

GUI package managers.

Dlls are only used to circumvent GPL and keep the source closed. Which isn't helping the case really. Any other use of dlls is simply unnecessary.

>that's why this FakeFact
Mac apps are generally smaller. But you can come up with massive binary examples from any platform because inefficient shit coders = fat binaries.

>circumvent GPL
GPL doesn't allow this. You must mean LGPL

GPL linking exception.

It's what macfags call "magic"

It just werks if you squint hard enough.

Dynamic libraries work great and make a leaner/cleaner system with centralized management of the system's capabilities.
Also, there's a great threat in having the same library from 10 different vendors inside your system, how many of them are the original and how many of them do more things?
Also static linking and especially when done in a folder that the user has write permissions, could potentially be altered by some other program and every time you call a wget-like function, it grabs the request and reports it to its master... That"s similar to library interposition.
The only good part of the static library is when you don't have su permissions and you want to run install something... But then again there's no other pro.
Static linking is for lazy or incompetent devs and stupid users. A user that can't deal with a missing library should just stay with android or ios... Which funny enough are so fucking regulated by apple and google that all the libraries are fucking dynamically linked.
Imagine having 10 ides and each one of them ships its own openjdk, gcc, g++, mysql, php, clang, gdb, valgrind,e.t.c. ...this is my 50MB ide with its 1.5GB dependencies.
That's a pajeet approach to programming.

Also fuck you with your "app" terminology. We are talking about programs.

Hey retards before you start flinging shit why don't you see that the future flat pak and all other app container solutions are pushing for: a hybrid

There is a place for flatpak entertainment software is a perfect example of when we shouldn't dynamically link, they are not rolling software that will get regular updates, it software whose development cycle is inherently limited intentionally and maintenance can't be expected. Another use case is Steam, we have a company that wants to port its application but is not part of the existing developer ecosystem and might not want or have the authority to deal with the nuances and bargaining with distribution maintainers and libraries to keep deprecations they depend on. But we shouldn't statically link libraries in major rolling release software like nautilus chromium kde when the people that are maintaining this software are on cubicle over from the person maintaining the library they depend on.

>Mac apps are generally smaller
Mac programs are almost always the largest ones.

You can use synaptic

That's what I meant.

it's actually easier on windows because it pre-selects the directory

why do you need a universal binary if you only use one thing?
it'd be more efficient to follow the UNIX philosophy here.

Programs like synaptic are good for a few cases.
I use synaptic when I want to search a keyword in a package.
When apt search throws 100 results in the terminal it's not the easiest data to read.
Upgrading, installing, resolving depndencies and a few other frequent operations are faster and easier in cli.
Also synaptic is handy when using multiarch(hint not all packages are available on both platforms)

lmfao, lost

Attached: Bild.538096.jpg (384x384, 32K)

This.
This is the reason the massive abomination called "winsxs" exists.
If the code was simply part of the binaries, it would at least be easy to remove.

>2. no, this is horrible because static linking

Sometimes it's hard to run older games because the dependencies they require are no longer in the repos.

itt PCfags sourgrapesing that Apple once again did things right

Attached: c01860850.gif (520x340, 53K)

Or worse it succescully links to a version which is so old that it tries to use features that are so old that they are no longer given deprecated status and appropriate error messages and the program fails trying to pass a pointer to nil

macOS' paradigm forces the user to be steward of their own machine and be responsible for file placement, rather than needless abstraction layers of "Wizards" that assume the user is an absolute idiot

Instead you should have posted the screenshot of 40 different versions of .net installed

>newer ones containing IA32 and x86_64 binaries
For what purpose? Not only has it almost a decade since the last version of OS X that even ran on non-64-bit hardware but there's a grand total of like a dozen mac models that can't run 64-bit programs.

Don't you wish mac users could poo in loo?

Attached: 1530918079191.jpg (643x960, 256K)

>if i repeat bullshit maybe someone will believe it

Well known apps (Chrome; Firefox; Adobe apps) are typically the same.

Microsoft shift is bloated beyond all human reason. Example: Xcode takes up 11gb while VS 2017 takes up over 80gb.

Other apps will depend on how efficient the developers were.

sudo apt install somepackage
sudo pacman -S somepackage
sudo dnf install somepackage

For the GUItards there's plethora of good package management frontends. But tracking the app down on a website, downloading it yourself, opening the DMG, dragging it into the folder, and then unmounting the DMG is so much easier.

>Dynamic libraries work great and make a leaner/cleaner system with centralized management of the system's capabilities.
Paper theory that has never played out in the real world.

>Also, there's a great threat in having the same library from 10 different vendors inside your system, how many of them are the original and how many of them do more things?
There's a greater threat from being able to compromise many apps by changing one file.

>Also static linking and especially when done in a folder that the user has write permissions, could potentially be altered by some other program
If malware has write permissions it can modify dynamic libraries as well. At that point modifying one library affects multiple applications including apps that you would otherwise expect to be safe. MyApp has a valid signature but relies on MyDLL which got FUCKED by a piece of malware or replaced with MyDLLv2 Compromised Edition.

>The only good part of the static library is when you don't have su permissions and you want to run install something... But then again there's no other pro.
In the real world dynamic libraries create a fragile system where every little change can break something you didn't even imagine could break. Installed the latest game patch? Now your web browser doesn't work. Uninstalled an old app you never use? WTF did your word processor just break?

>Static linking is for lazy or incompetent devs and stupid users.
It's anti-fragile.

>A user that can't deal with a missing library
Nobody wants to deal with that stupid shit.

>Imagine having 10 ides and each one of them ships its own openjdk, gcc, g++, mysql, php, clang, gdb, valgrind,e.t.c. ...this is my 50MB ide with its 1.5GB dependencies.
Imagine one IDE demanding a PHP update and breaking the other nine.

I've been at this longer than you kid, and dynamic libraries have ALWAYS been shit in the real world.

Microsoft is literally an Indian company now. But somehow you think it's Apple users who can't poo in loo?

Attached: microsoft.jpg (650x367, 43K)

stop it, stop telling the truth! you'll anger the ricers!!

MACTODDLERS BTFO

Attached: 1510824279633.gif (325x235, 1.59M)

>I do not want this program
>This is the only one of it's kind Apple approves
>I guess I have to use this program

It's easy because it's your only choice.

What Apple'nt

>Paper theory that has never played out in the real world.
except on literally every OS
>There's a greater threat from being able to compromise many apps by changing one file.
>If malware has write permissions it can modify dynamic libraries as well.
"static linking causes less malware" isn't a valid argument because code signing on dynamic libraries prevents this type of attack, meanwhile there is no easy fix for statically linked program that has accidental security vulnerabilities, which is statistically more of a problem than malware
>In the real world dynamic libraries create a fragile system where every little change can break something you didn't even imagine could break.
yeah dude if only there was a known process for OS distributions to prevent this, it's almost like they should be split into stable and testing or something like that, too bad none of them actually do that mirite?

>>Paper theory that has never played out in the real world.
>except on literally every OS
They are a nightmare every where they are used.

>meanwhile there is no easy fix for statically linked program that has accidental security vulnerabilities,
If a DLL has an accidental vulnerability it affects every app which uses it and code signing cannot save you from this.

>>In the real world dynamic libraries create a fragile system where every little change can break something you didn't even imagine could break.
>yeah dude if only there was a known process for OS distributions to prevent this, it's almost like they should be split into stable and testing or something like that, too bad none of them actually do that mirite?
WTF are you talking about? Do you seriously believe that a "stable" release never has bugs and never breaks legacy code?

When you get out of junior high and get some experience in the real world you'll understand.

So, all of your arguments are "it's difficult".
When you don't have to use monkeys for programmers.
People are building kernels with 20000000 loc and have OSes(debian) with 60000 packages.
If you, as a dev and os maintainer, can't keep up with a few tens of libraries... You should change jobs.
Also your arguments are not the best ones out there. If your average user has write access to your lib folder, your os is shit.

They can though.

based and ELFpilled

>If a DLL has an accidental vulnerability it affects every app which uses it and code signing cannot save you from this.
Oh my fucking god.
Where the fuck does your program get the lib in the first place? From the same fucking source your os maintainer got it.
If his copy has a vulnerability, your copy has a vulnerability.
How are you going to maintain a system where every program runs it's own version of libraries? Are you going to keep track of every version of every library out there?
You trust one version and that's the current stable. If you download a legacy piece of shit s/w and it gives you an ssl library with heartbleed, you are fucked... But hey at least it's easier to solve dependencies that way.
I swear... Jow Forums has better system programmers than Jow Forums

The joke here that people aren't getting is that you won't even be able to run xcode because of that little cross out on the icon; broken compatibility or something like that.

The main thing that bothered me about programming on macs after leaving mavericks was that everything was gone (compilers, even makefile) that I would use to work; I needed to install xcode-tools even though I would never open the xcode IDE on purpose in my life.

>If a DLL has an accidental vulnerability it affects every app which uses it and code signing cannot save you from this.
then you test and update the DLL, packages that can't update for whatever reason can have static linking as an option, but it's the exception
>Do you seriously believe that a "stable" release never has bugs and never breaks legacy code?
no, my argument is that static linking does not actually decrease bugs or remove the burden of testing, in a lot of cases it INCREASES it because now you have a bunch of integrated vendor code you're responsible for, the only reason to mandate that it must be done is if you are deploying into legacy/embedded environments
>When you get out of junior high and get some experience in the real world you'll understand.
whatever "real world" you live in is shit, get a better one

>Imagine having 10 ides and each one of them ships its own openjdk, gcc, g++, mysql, php, clang, gdb, valgrind,e.t.c. ...this is my 50MB ide with its 1.5GB dependencies.
I don't need to imagine this, this is happening in the real world with dynamic linking. The only difference is, with static linking dead code elemination works out way better (among other optimizations), so at least all those baked-in versions are smaller.

>INCREASES it
They won't believe you.
They won't believe also that debian jessie(iirc) released with zero bugs as stable, just because they made every part of the ecosystem. Your system was as vulnerable as the proprietary binary you ran on debian, and everything else were as secure as guaranteed by the debian maintainers.

>1 shared version is the same as 10 same copies
Okay, this thread have crossed the line of common sense.

>debian
>zero bugs
Actually, who would ever believe this.

>imagine being this gay

Believing in "shared libraries" on Windows is purely retarded and on Linux it's at least naive.

>t. arch user

>So, all of your arguments are "it's difficult".
It has proven, over and over again during the past four fucking decades, to be extremely fragile in the real world.

>>Oh my fucking god.
>>Where the fuck does your program get the lib in the first place? From the same fucking source your os maintainer got it.
>>If his copy has a vulnerability, your copy has a vulnerability.
>there are never different versions of a library
>bugs never appear in later versions
>intended changes never break older code
>bahbees first CS class in Bombay

>How are you going to maintain a system where every program runs it's own version of libraries? Are you going to keep track of every version of every library out there?
I'm not going to care because statically linked apps don't break when something unrelated is upgraded or changed.

>>You trust one version and that's the current stable. If you download a legacy piece of shit s/w and it gives you an ssl library with heartbleed, you are fucked...
>every app is a publicly facing internet app that absolutely needs the latest version of every library the second the fucker is available or the world will end

>then you test and update the DLL,
>you can find every problem with a test

>>Do you seriously believe that a "stable" release never has bugs and never breaks legacy code?
>no, my argument is that static linking does not actually decrease bugs or remove the burden of testing,
I never said it did. What it does is REDUCE FRAGILITY. A self contained app will run so long as the underlying OS APIs and processor instruction set remain the same.

>whatever "real world" you live in is shit, get a better one
Stick your head in the sand and imagine real world problems don't exist.

Also this: The greatest sign of DLL theory failure is the DLL versioning issue.

>there aren't multiple versions of DLLs on systems which widely use them
There's sand, and then there's your head. Guess where your head is?

cd [anywhere I want] -> sudo apt install

>you can find every problem with a test
yes, you can, your testing probably isn't good enough
>reduces fragility
meaningless statement, your program not working on systems you claim to support is a bug
>A self contained app will run so long as the underlying OS APIs and processor instruction set remain the same.
which is never because literally every modern OS ships a bunch of dynamic libraries that re upgraded every release and that you must link against

>brainlets can't into file system

nah, that would be like hating muslism but at the same time loving christianity

>>you can find every problem with a test
>yes, you can, your testing probably isn't good enough
You literally, mathematically cannot.

>>reduces fragility
>meaningless statement,
It's the experience of pretty much everyone over the past four decades.

>>A self contained app will run so long as the underlying OS APIs and processor instruction set remain the same.
>which is never
I love how you just ignore the real world. I've got ancient shit that will run on Mac OS and Windows 10. But it tends to be the self contained shit.

> found guilty of the evil wrongthink by another Jow Forumsentoomen

Oh no :(

>It's the experience of pretty much everyone over the past four decades.
the experience is shipping things without having to test anything?
>I love how you just ignore the real world.
let me repeat: your "real world" is shit, get a better one
>I've got ancient shit that will run on Mac OS and Windows 10. But it tends to be the self contained shit.
and for the other 99% of programs out there, people have to do actual work to keep them running, but keep on pretending like that isn't the case
>You literally, mathematically cannot.
oh sorry i guess we should all just give up making things then

Because that way you only need the one binary regardless of what platform you're on. Notice how OS X's the only one to have a single option.

Now that 32-bit support's killed off those are dwindling in numbers, I'd imagine soon we'll start seeing universal binaries with x86_64 and ARM64

Attached: Screen Shot 2018-11-02 at 17.21.16.png (773x315, 38K)