C4 Engine Drops Linux Support, Calls It "Frankenstein OS"

[bitman]

application named sed? sure, due to path order it could break your system. the hoops you needed to take? it's like watching Dumb and dumber. it's like me asking what hapens if i create application user.exe and compile it to system folder on windows. it's not OS problem, it is PEBKAC

See fact that it would break sed is the problem. Problem is ALL applications being in same spot. It is a giant mess. Of course not many would want to make their own app named "sed". My point however was possible application name clashes.

library versions? mostly package management restriction for the sake of sanity. each .so is still branded with its version. and there is a thing called order in which library is searched for. just like anywhere else you're free to just put .so in same folder as application.

if your application resides on more than one place, don't try calling it portable. it is not

Problem is implicit linking to libs in OS. This is really really bad. And everyone is doing it. Thats why going cross-distro is such a pain in the rear.. No problem on windoze because stuff available with system is always on every version of OS and its incrementally improved. And rest of libs user has to take care of. Honestly package managers be they very comfortable and nice - they should manage only system components, not user software. But it is what it is..

if glibc broke compatibility, there was a good reason. maybe you should look up the reasoning behind it

Dont get me wrong, windows does similar thing. New symbols introduced and if one targets newer OS api level then app will not run on older OS. But we can explicitly pick API level and we wont link to newer symbols thus application will run on older OS.

so, simply WIN_VER=0x501 and bunch random crap... about the same on linux, you just need to be as familiar with it as with windows. the so called easy is gibberish for me, but i can deal with same problem on linux without problems.

Wrong. You cant target explicitly glibc api version. There is some hacks from gnome people using .symver but its not officially supported.

you seem to know one OS and expect to not learn for others, but rather other OSes to be as OS you know

I know things work painlessly on one OS and i expect other OS not to be bitch about it. Is that so much to ask?

>[*]Very difficult to build portable (across distros) software.

Depends. Depends on the dependencies.

Well it should not. The only painful thing on windows is building stuff developed on linux.

>[*]Distros depend on rather new version of glibc anyway which forces user to rebuild all of dependencies.

Normally you distributor cares about this for you. You only have to recompile if you have manual installations or if you are using Gentoo (or the likes).

Point is libs shiped with distro can not be redistributed hoping they will work elsewhere.

> Enter chroots of old distros

Is there any form of chroot under windows?

Nice thing is that i never needed one. Chroot is used to avoid any implicitly linked libs. Seriously implicit search paths that provide access to other than core system libs was retarded idea.

It is also not the point of Linux to be some Windows clone. Also not in terms of operating system architecture.

Linux does not need that. Far from it. All linux distros need is a sane way to write all kinds of software. It must be developer-friendly. Its great for foss but painful otherwise.

[justmy2cents]

Runtime libs can override the system ones on Windows too. That's why Windows typically ends up with a gazillion versions of the MSVC Runtime Library installed, since every game wants to install and use a different one. And 99.99% of the time, you can uninstall all of them and just use the system one just fine.

yep, i know. most of the http://msdn.microsoft.com/en-us/library/7d83bc18.aspx also applies to Linux. i just posted you where to look since you don't know how to do it in Linux. and there is a big difference in customization, where windows fails to be as flexible

while both try to load from executable and current dir first, windows next choice is system one and then after that it loads PATH. Linux on the other hand specifies next choice with LD_LIBRARY_PATH and then after that rpath and ld.conf making something like global runtime pretty trivial even when same libraries reside in system folders

I make claims based on the threads I see posted here. And while I don't personally run Linux OSs anymore, I still have to interact with them at work.

Then again, we got a VAX/VMS server backed, a Windows 3.1 PC, some DEC hardware we need to keep running, and one of these.

now, just think. how many % of people post about bad and how many about good?

[DanielG]

while both try to load from executable and current dir first,

No, Linux does not look at the current dir or the directory of the executable, unless it's set with LD_LIBRARY_PATH or via RPATH.

[blackiwid]

There's only one platform that matters if you want to make desktop game, windoze. Of if you are a cell phone game making retard, you have to deal with crapple.

We all have no glass-ball but it will even if you think very conservative change very much when this year steammachine "konsole" gets into the market. Maybe its not the 15-20% gaming market I think it will become pretty fast, at least within a year. konsoles sell also not everyone on day 1.

So let it be only 5% that with maybe 5% current users that also switch their gamingmaschine to linux, like I will do. is a market noteworthy in my oppinion, Wii got also much games even in comparsion of the rest of the market was a small thing and every game had to be designed specialy for the wii alone, because you could not scale anything to its 8bit ram down and to normal maschines up.

I prognose it will either fail totaly or will be the dominant gaming plattform at least for the pc in 2 years. So for a engine it would be good to support steamos more or less before it gets out, because the game devs need also some time to make the games and you dont want to land with games for linux in 2-3 years maybe?

[Cyber Killer]

See fact that it would break sed is the problem. Problem is ALL applications being in same spot. It is a giant mess. Of course not many would want to make their own app named "sed". My point however was possible application name clashes.

It would not break sed, unless you'd put it in the same place as sed, overwriting it, an unlikely scenario. It might cause some problem if you'd put it in a search path directory that is being checked earlier than the one where the real sed is, also unlikely. Not to mention that all non-distro packaged software should be installed in it's own subdirectory in /opt, and the binary should be called with full path (opt is not on the search path). So really, without trying on purpose to break the system, there's no real danger of naming your binary however you like.

[justmy2cents]

See fact that it would break sed is the problem. Problem is ALL applications being in same spot. It is a giant mess. Of course not many would want to make their own app named "sed". My point however was possible application name clashes.

unless your app is not part of the distribution or at least intended, it should never reside in system folders. mine never do and i have 0 problems. you introduced PEBKAC, not system flaw. you can set any Windows file in update on reboot and replace it with damn txt if you like. is that Windows fault? off course you could say you need admin to do that, but just think... which OS was last in line to abolish absolute Administrator by default?

Problem is implicit linking to libs in OS. This is really really bad. And everyone is doing it. Thats why going cross-distro is such a pain in the rear.. No problem on windoze because stuff available with system is always on every version of OS and its incrementally improved. And rest of libs user has to take care of. Honestly package managers be they very comfortable and nice - they should manage only system components, not user software. But it is what it is..

no OS solved this beyond it's crippled, but hey... it works. first actual solution will be application containers.

Dont get me wrong, windows does similar thing. New symbols introduced and if one targets newer OS api level then app will not run on older OS. But we can explicitly pick API level and we wont link to newer symbols thus application will run on older OS.

wrong, you can link against older dll where newer is different beast completely, not pick which API. and what if they stop supplying something like mscvrt80.dll for some release? now, here is even better questions, how many beside MS keep this track? how many security problems do you introduce with unpatched zillion of same libs since system update is so inconsistent on Windows?

I know things work painlessly on one OS and i expect other OS not to be bitch about it. Is that so much to ask?

YES! in current state. but, more so it depends which OS you expect to be like which. someone new to Windows will have exact same voes as someone new to Linux. OS is different. period. learn or call it bust

Well it should not. The only painful thing on windows is building stuff developed on linux.

based that no OS came beyond crippled workaround... YES!!

[JS987]

From this I suspect you're one of those people who remove PulseAudio without even trying it

Does PulseAudio support changing volume using amplifier of sound card, when digital audio data always goes from audio player to DAC unmodified (without distortion)?

[bitman]

It would not break sed, unless you'd put it in the same place as sed, overwriting it, an unlikely scenario. It might cause some problem if you'd put it in a search path directory that is being checked earlier than the one where the real sed is, also unlikely. Not to mention that all non-distro packaged software should be installed in it's own subdirectory in /opt, and the binary should be called with full path (opt is not on the search path). So really, without trying on purpose to break the system, there's no real danger of naming your binary however you like.

Fair enough But would still have this problem if say i made my own ppa and packaged some software. Even if recompiled blender or something. Core system software in one spot on search path - fine. But user apps totally do not belong in there.

wrong, you can link against older dll where newer is different beast completely, not pick which API. and what if they stop supplying something like mscvrt80.dll for some release? now, here is even better questions, how many beside MS keep this track? how many security problems do you introduce with unpatched zillion of same libs since system update is so inconsistent on Windows?

Actually i meant OS dlls, not runtime. But hey - as long as your app bundled that runtime no matter how old it is it would still work. As for security - its software vendor's problem. If software is mission-critical then pick a good vendor. If its some abandonware - then it most likely isnt that important/critical anyway.

YES! in current state. but, more so it depends which OS you expect to be like which. someone new to Windows will have exact same voes as someone new to Linux. OS is different. period. learn or call it bust

Oh man i dont care. As long as it works. Like now im battling with cmake and lsb in order to compile openal which does not link to stuff provided by distro. No matter what end i pull it still links to latest. And trust me i nearly exhausted every option. This is bad and it would never happen on windows. Or if it did there always is a list to remove some linker search paths. Anyway explicit > implicit always. Some linux people forgot it and its being big pain in the rear..

[Cyber Killer]

Fair enough But would still have this problem if say i made my own ppa and packaged some software. Even if recompiled blender or something. Core system software in one spot on search path - fine. But user apps totally do not belong in there.

Making a custom repo is trying to break stuff on purpose :-P. Though I think that if you try to go through package management it will probably (I didn't try this myself, hence probably) not allow a user to install a package that provides the same filename on the same path (package managers have the list of all files installed from all packages). I think you'd get a message that there's a conflict. BTW: Custom packaged software (outside of official distro repositories) should also obey the /opt location rule.

Whatever your opinion might be, the directory tree and file locations (and package management and deployment) is a really well thought out scheme.

[Xaero_Vincent]

Speaking of application distribution and the ability to have multiple versions of the same applications... I'm surprised nobody mentioned portable apps.

Essentially, if a developer is looking to support multiple distributions but doesn't wish to learn the packaging format for those distros, worry about different library dependencies, nor rely on other distributions developers and/or users to package their software, they can just encapsulate the whole application into a portable executable that has self-contained dependency libraries and just build and link everything with an older glibc (compiled in a VM running an old distro or perhaps chroot). For instance, maybe set the minimum glibc base for your app for Ubuntu 12.04 LTS, Debian 7, or CentOS 6 then once say Ubuntu 16.04 LTS is released, recompile and rebase your application to work with the glibc from Ubuntu 14.04 LTS, or any stable distro from 2 or 3 years ago. This ensures the portable apps works across most distributions people use but also keeps your development environment somewhat modern.

I've actually used this system to run some games before but supports most types of applications. It works rather well.

http://portablelinuxapps.org/