Transition to Linux

Pages: 12
Having to compile everything instead of just downloading binaries is retarded.


I don't think that is fair. Windows binaries are easy to share because there is only 32 and 64 bit Windows ( assuming backwards compatibility ). There are so many flavors of Linux that it doesn't make sense to share binaries.
How can binaries be incompatible across distros?
I don't really understand, given that a modern Ubuntu setup (or hell, even a poorly setup Arch linux system) will automount USB drives


It automounted it... just as read-only so I couldn't copy a file to it. So I had to manually unmount and remount. I ended up writing a script that I had to manually run every time I plugged in the drive. It was retarded.

And again, not everything is built from source on Linux.


bSNES was. So was some other media program I wanted to try out but couldn't because a binary was unavailable and the source had too many weird dependencies to compile.

The key difference here is that "not everything" is built from source on Linux -- this is true... however NOTHING is built from source on Windows or Mac. Because it's stupid to expect that of the user.


But like I say... if you stay in the repos, it usually works fine. But if you want to just grab random shit off the web and try it out (which I do all the time), you run into mountains of problems.

Software vendors can produce binaries for Linux users as well, contrary to popular belief, much like a PE executable. They just don't


Bolded for emphasis.

They just don't. So what can be done doesn't really matter... because the reality of what is actually done is different.

packages like that are often instead introduced via distribution packages: https://apps.ubuntu.com/cat/applications/bsnes


At the time, bSNES was not available there. Either that or I couldn't find it (and I looked)

But again... distribution packages frequently broke for me because of dependency and version issues.

EDIT: This just also goes to show how behind the times the repos get and one of the major reasons why I had to frequently step outside of them.

bSNES changed its name to 'Higan' ?a year ago? (maybe longer)... so whatever is in that repo is out of date. If you want to get the most recent version, you have to compile it from source.

http://byuu.net/higan/ <- Author's page. Note: no Linux binary. No distribution package.

/EDIT

New software will sometimes compile binaries for convenience purposes until its well adopted.


Bolded for emphasis. Though really, in all my time on Ubuntu I don't think I ever found a downloadable binary once. Everything was either a package from a repo or compiled from source.
Last edited on
Here's a definite advantage of Linux: you can replicate an identical system on all your machines, with identical setup everywhere. In that respect Ubuntu completely trumps windows. Both my laptops, my mom's laptop, her desktop, and my work desktop have identical setup. Since the time I switched my mom to Ubuntu, when I go home I don't have to spend an entire day trying to fix her computers.
Last edited on
Lowest0ne wrote:
I don't think that is fair. Windows binaries are easy to share because there is only 32 and 64 bit Windows ( assuming backwards compatibility ). There are so many flavors of Linux that it doesn't make sense to share binaries.


Being able to explain why it is the way it is does not mean the way it is doesn't suck. A weakness is still a weakness even if it can be explained.

If anything... you are making a selling point for Windows: it's uniform. Whereas Linux is a jumbled mess.
Last edited on
I have to say I like Linux...
But I've found all Disch points to have some truth.

I remember myself making a script to be run on system startup to automatically mount my secondary harddrive ( containing a broken w7 install ) and to disable mouse acceleration ( with that risky line containing my mouse's device name used to identify it ).

But I managed to run No$GBA on it, and I was happy.

Edit: I also remember manually downloading updates from my mobile.
The official website (found through google) listed all dependencies... which had more dependencies inside.
It took me three days sitting on the stairs using my neighbor's wifi.
Eventually my mobile ran out of ram with 15+ pages open and I had to begin from the last point I remembered.
Last edited on
Okay, only the 4th... count em... 4th time I've re written this post because of lack of draft saves and disconnects....

1) Windows doesn't have a solution for versioned libraries. Linux does. However, the problem is addressed differently. For instance, A lot of third party software is distributed via packages, where versioning is handled at compile-time. For the case of Windows, the common practice is to compile with a bunch of libraries and then distribute the libraries as well. That doesn't make one better than the other, it's just two different solutions. That said, you can do the exact same with a Linux executable... contrary to popular belief (where is this coming from?)

2) Bad versioned and dependency issues are solely on the user. apt-get is crap... but the GUI for apt-get is clean. To break apt-get you have to explicitly open a terminal and screw it up. I see it every single day where people go through hell and back to break their local repository and/or local installations. It usually stems from the idea that you can't get what you want from the repository so they venture off into 3rd party land to find software.

The problem is that about 98% of the time this happens, the software is in the repository... and about 50% of the time, it's already installed. That's why bad dependencies and versions happen... because people explicitly open a console, force the command to install an out of date library, then wonder why everything is broken when the package manager is confused by an outdated or weirdly versioned package.

It's like explicitly replacing a core library on a Vista installation and replacing it with its counterpart from Windows 95. It's going to break stuff....

3) bsnes has no reason to provide binaries as its distributed with almost every single distribution repository. Those that don't have 3rd party packages that provide them. I'm not sure why you couldn't find a package but how the hell are you going to blame the entirety of Linux for that?
To me installing out-of-repo software is equivalent to hand-editing the Windows registry.

Have you ever totally screwed up your Windows system via hand editing the registry? I have. Had to re-install system and even format drive to get rid of the faulty registry (I wasn't aware of any way to restore it). So, if anyone says that it is very easy to mess up your Linux system by going out of repo - it is dead easy to mess up your Windows by editing the registry. Not to mention the virus I got on Windows by browsing the internet. And that was a legal Windows copy!

If you do dangerous things with your system, you can bring it down in both the Windows and the Linux worlds. However, for standard use - such as mine - Linux never breaks. And I do run an Apache server as well as a custom web server written by me, program in C++, use svn, text comparison tools, have a fully blown LaTeX installation, SAGE (perhaps the most advanced computer algebra system, not available on Windows last I checked) and GAP (another computer algebra system).

Installing all of the above software consists in remembering the name of the program and typing sudo apt-get install in front of it. I can also install those with the Ubuntu software center, but that takes way too long (I prefer pressing ctrl+alt+t and typing the apt-get command).
Last edited on
NoX wrote:
1) Windows doesn't have a solution for versioned libraries. Linux does.


I agree Linux has a solution. But Windows also has a solution.... and it is typically what you said in your post: The libs are distributed with the program. Which, quite frankly, is a much better solution.

The downside is... you end up with duplicate libs... but in the modern days of terrabyte harddrives, does that really matter? The likelihood of the user having a problem with the libs literally drops to zero, which is a huge upside and far outweighs such a minor downside.


NoX wrote:
2) Bad versioned and dependency issues are solely on the user. apt-get is crap... but the GUI for apt-get is clean. To break apt-get you have to explicitly open a terminal and screw it up. I see it every single day where people go through hell and back to break their local repository and/or local installations. It usually stems from the idea that you can't get what you want from the repository so they venture off into 3rd party land to find software.


So yeah... it's like I said. Stepping out of the repos = Ubuntu explodes. That sucks.

Effectively... that means you can't use Linux reliably if you plan on using 3rd party software.

Explain to me again how that isn't completely shitty? What's the point of running an OS if the only thing you can run on it has to be picked from a limited library of [frequently out of date] software?

bsnes has no reason to provide binaries as its distributed with almost every single distribution repository.


1) That wasn't always the case. Keep in mind I tried to get it 4-5 years ago when it was relatively unpopular and the snes emu scene was dominated by zsnes and snes9x. The only people who even really knew about bsnes (let alone cared about giving it a try) were people in emulator development (which I was at the time). So I couldn't find it in the repos because it probably wasn't there.

2) And again... bsnes hasn't been called bsnes for quite some time. It's called Higan now, and has been called that for at least a year. So that repo you linked to is at least a year out of date. And guess what I get when I search for Higan?

https://apps.ubuntu.com/cat/search/?q=Higan&op=

"No applications found"


3) bsnes is just one example. The idea that Ubuntu repos will have every application every user will ever want is pure insanity. There's no way it can possibly accomplish that goal. So sooner or later... anyone who is into cutting edge software is going to have to step out of the repo. Which means they will inevitably break their system.


4) And again... none of this is ever a problem on Windows or Mac. You can download and run whatever you want on those systems and, assuming the program isn't malicious, your system remains intact. This is only a problem with Linux. And it's a huge shortcoming.


Those that don't have 3rd party packages that provide them. I'm not sure why you couldn't find a package but how the hell are you going to blame the entirety of Linux for that?


It's not a problem with Linux per se. It's a problem with the way software on Linux is developed and distributed. It may not directly be Linux's fault... but it's a problem that only exists on Linux.

tition wrote:
To me installing out-of-repo software is equivalent to hand-editing the Windows registry.


That's ridiculous. Installing out-of-repo software on Linux is the same as installing out-of-repo software on Windows.

Like I said above... on Windows I can literally download and run anything I want without risk of damaging my system (unless the program is malicious).

Hand-editing the registry is not even in the same ballpark as downloading programs off the internet.

EDIT: A better analogy would be to say that hand-editing the Windows registry is comparable to hand-editing xorg.conf. IE: you're messing with fragile details about system operations that are easy to screw up if you don't know what you're doing.

But running software? Not even close to the same thing. /EDIT


If you do dangerous things with your system, you can bring it down in both the Windows and the Linux worlds.


I agree.

My point is that installing programs should not be dangerous to my system. That's a huge flaw.
Last edited on
on Windows I can literally download and run anything I want without risk of damaging my system (unless the program is malicious).


and may I add to "malicious": a program may damage your Windows system if it is badly written or of poor quality.

In my opinion, out of repo programs that break compatibility are to be thought of as poorly written programs, rather than as of inherent problem of Linux.

On another note, if you work with Linux as your main system, you will get into troubles with Windows. My teaching slides compile perfectly on all Linux machines, but on windows I am getting a weird bug due to some program in the stack being out-of-date or wrong version or whatever. Since I have no Windows machine to test, I have to be on-call by when my windows-using colleagues complain that my stuff doesn't work. Not nice at all!

Main development of LaTeX appears to happen on Linux, so for mathematicians, Windows is the troublesome system.
Last edited on
1) Windows doesn't have a solution for versioned libraries. Linux does.

Solution 1: Compatibility mode. When an application relays on discontinued functions from libraries that are always dynamically linked the user may choose to run it in compatibility mode which provides support for those functions while sometimes also providing an additional layer of stability or isolation to account for the reasons those functions were discontinued to begin with.

Solution 2: Windows Side by Side (WinSxS):

A.) Application manifest files are files that are either included externally in the same directory as an executable or compiled into the executable as a resource. These manifest files are XML type documents that contain the names versions and sometimes even a hash to identify the version of the library that the application should link to. The Windows application loader is told whether or not an application uses a manifest file by the status of the '/ALLOWISOLATION' flag in the DLL Attributes section of the PE header.

B.) Configuration files are files that are present in the same directory as the target binary that tell the loader to check the local directory for versions of the library before checking any other directory in the search path. Caution should be used with this approach since libraries often link to other libraries by relative path, so if the correct version of every file is not included then this will break.

Solution 3: Directory redirection. In order to maintain compatibility with 32-bit applications running on 64-bit systems, applications that are not designated PE32+ in their header have their search paths redirected to special directories and registry entries that contain the 32-bit versions of the libraries they require. This redirection is done completely independently of the binary so legacy applications do not need to be redirected.

For instance, A lot of third party software is distributed via packages, where versioning is handled at compile-time.

Orca actually does provide functionality similar to what you are describing. There are far too many classes for me to name them all but look-up 'Win32_ActionCheck', 'Win32_Condition' and 'Win32_BindImageAction' to get an idea of how much granulation is available. In terms of functionality it at least goes head to head with CMAKE, at times it might say that it is actually better but I'll allow that my opinion may be because I don't know CMAKE well enough. The trouble is that nobody really uses it to its full potential because, as it often does, MS allowed it to get to a size where it is too intimidating for most users.
Topic archived. No new replies allowed.
Pages: 12