Originally posted by disi
View Post
Announcement
Collapse
No announcement yet.
Update On The GOG Game Service For Linux
Collapse
X
-
-
MAC hrhr
Pay What You Want for Interplay Games, GOG goes Mac, and other great news from our Conference.
They even send bloody advertisement to Linux customers
Who is actual using Apple computers? I know a lot of people with those brick-phones, while I use a small handy one from Sony.
I have yet to find one of those people who really do use and have Apple products... they must be concentrated in the USA?
Leave a comment:
-
Originally posted by DebianLinuxero View PostWell, finally GoG had its October event and the news is that Linux will not be supported in the near future.
What a bullshit.
MAC version had a barely 1000 votes request vs a 7000 plus Linux one.
Even Desura and Humble Bundle that were smaller have the balls to be on Linux.
I'm very dissapointed.
I know we can argue that the Humble Indie Bundles/Desura etc sell a lot of games to linux users but they arent looking at that, we will have to wait for Steam for Linux before we see GOG/CDPROJEKTRED wetting their feet in the Linux pool. And remember also Steam did the samething they debuted for Mac before they officially announced Linux Support.
Leave a comment:
-
Dissapointed
Well, finally GoG had its October event and the news is that Linux will not be supported in the near future.
What a bullshit.
MAC version had a barely 1000 votes request vs a 7000 plus Linux one.
Even Desura and Humble Bundle that were smaller have the balls to be on Linux.
I'm very dissapointed.
Leave a comment:
-
Multiarch is not always unproblematic, it introduces some stupid side affects as well. Especially when you try to install i386 binary only printer drivers (like those funny ones from brother). Then you get extra depends of i386 packages which can hurt the system during updates (which are btw. not even really needed - you could hack the package to be "all" and use it without). I also did not manage to compile wine (32 bit) on wheezy/multiarch yet - i dislike using a chroot for that part (i also wanted to compile doom3 gpl 32bit as well but did not succeed). It can solve problems but introduces new ones. Maybe it is better with rpm based systems as they switched earlier.
Leave a comment:
-
Originally posted by shmerl View PostDebian already introduced multiarch, which is a good and flexible approach: http://wiki.debian.org/Multiarch
In the past, this was the most common show stopper for the users close to me--They would have some 32-bit application or userspace driver (usually for a printer) that could not install due to an unavailable library. Once that happened, Linux usually got too intimidating.
(As an aside, the most common usability issues for Fedora were usually due to the X.org release being too new for proprietary driver support or due to something SELinux-related. You just need to add "check for interference from SELinux" after "check the firewall." But it's a MAC implementation--It's not doing its job if it doesn't get in the way! )
It will be water under the bridge after this development is complete. The spec is interesting, and if it works out well, hopefully the file system changes will get blessed and picked up by other distros.
Leave a comment:
-
Debian already introduced multiarch, which is a good and flexible approach: http://wiki.debian.org/Multiarch
Leave a comment:
-
Originally posted by ownagefool View PostIf the main reason you prefer yum over apt is because you find yum more usable, you'd probably be happier with aptitude over apt on a debian based system.
Let's screw compatibility for fun, just because we think that /usr/lib needs to represent the preferred ABI. Well, that and they didn't want to make a special case in their tools for x86_64 (never mind the existence of the /usr/lib32 directory...). If they had followed the FHS and LSB standard, all the Debian distros ought to have been able to use the existing 32-bit library packages directly, at least eventually. Then, 32-bit application support wouldn't have been limited to the nearly worthless ia32-libs.
As for everything else related to these formats and systems, rpm vs deb, yum vs apt, they're the same. The UI may be different, but I haven't noticed any major differences in their capabilities.
For GOG, I imagine there are some legitimate compatibility concerns (e.g. can a glibc ABI change cause the program binary to break?), but I'd be curious if they're mostly daunted by the number of Linux distros and how many setups they might need to replicate in order to provide support.
Leave a comment:
-
Originally posted by glasen View PostFor those games which have a native Linux version, GOG can use the "Humble Indie Bundle"-way, providing at least and tgz-archive in the download-center. All Humble Indie Bundle games are packaged so that they can run on a bunch of distributions.
See for example Torchlight:
This game runs flawlessly on Ubuntu, Fedora and OpenSuSE. And this game is not a small SDL-based 2D-game. And all HIB provides is a single installer-package which includes all necessary binaries and libraries (Those who are not commonly provided by the distribution. In this case libOGRE).
Today distributions are no comparison to the ones a few years ago. Inter-distribution-compatibility is much better than people commonly think. There are many applications which run flawlessly an all different kind of distributions even if they where only tested or certified for a single one.
The biggest problem today is to run an old binary-only Linux-games or applications on a modern distribution. But modern applications or games are not a big problem.
Leave a comment:
-
Originally posted by Ericg View PostI know this discussion is going to end up here anyway so im just trying to be ahead of the curve... standardization of packages on the linux desktop?
Format: RPM
Frontend: PackageKit
Justification:
1) PackageKit-- distro agnostic, backend agnostic (packagekit can even hook into pacman for christs sake)
2) RPM-- I know people get really up in arms about RPM vs Deb but my personal vote goes to RPM because Enterprise already does RPM (RHEL + CentOS) and you can do delta packages. Maybe delta's are more an issue of apt-get vs yum but under Debian you download the whole new package, under Fedora you only get the binary difference. I like delta's.
I realize because of Ubuntu that .deb has kind of become 'the standard' for desktop but really it'll probably come down to punching match between Red Hat and Canonical then between RPM and Deb since Ubuntu has desktop and Red Hat has enterprise unless by some miracle they can come together and settle on a package format and package manager (again..yum..please. yum search is so much saner than apt-cache search).
For libraries either run statics, supply them yourself, or have distros package all versions of a libraries wherein there was an ABI break so that we can just run stuff across the board as long as its ABI compatibile (obviously if there was an API break then its an ABI break too) this way when you install the package it just pulls in the library dependencies it needs from the repos
disclaimer: no, I'm not one of those "We need a stable kernel interface! Backwards compatibilty for 20years!" guys, or even release to release. I actually have no problem breaking BC, but if they are going to mandate specific library versions then thats probably the best way to do it.
aptitude update apt-get update update package archive metadata aptitude install foo apt-get install foo install candidate version of "foo" package with its dependencies aptitude safe-upgrade apt-get upgrade install candidate version of installed packages without removing any other packages aptitude full-upgrade apt-get dist-upgrade <package> install candidate version of installed packages while removing other packages if needed aptitude remove foo apt-get remove foo remove "foo" package while leaving its configuration files N/A apt-get autoremove remove auto-installed packages which is no longer required aptitude purge foo apt-get purge foo purge "foo" package with its configuration files aptitude clean apt-get clean clear out the local repository of retrieved package files completely aptitude autoclean apt-get autoclean clear out the local repository of retrieved package files for outdated packages aptitude show foo apt-cache show <package> display detailed information about "foo" package aptitude search <regex> apt-cache search <regex> search packages which match <regex> aptitude why <regex> N/A explain the reason why <regex> matching packages should be installed aptitude why-not <regex> N/A explain the reason why <regex> matching packages can not be installed
Leave a comment:
Leave a comment: