| |||||||||||||
Why Steam on Linux matters for non-gamersWhy Steam on Linux matters for non-gamersPosted Sep 22, 2013 14:45 UTC (Sun) by krake (subscriber, #55996)In reply to: Why Steam on Linux matters for non-gamers by khim Parent article: Why Steam on Linux matters for non-gamers
> Try it.
My software is currently packaged by a respective service provider so I don't know exactly how they do it, but I might be intrigued enough to try for myself next time I create something new.
I would expect that publishing times vary quite a lot between channels, just like they do on mobile app store channels.
As far as license restrictions are concerned, there might be some for Linux distribution channels just like there are for app store channels. Since I haven't read up on any respective legal documents I can't say for sure but I would be surprised if would be more limiting than mobile app stores.
Well, for GNewSense maybe, but then that is their goal.
(Log in to post comments)
Why Steam on Linux matters for non-gamers Posted Sep 22, 2013 17:03 UTC (Sun) by khim (subscriber, #9252) [Link] IOW: you don't know anything about how distributions work, you don't know anything about their strength and weaknesses and you only assume they behave in some way you expect them to behave. Sorry to disappoint you, but they don't behave like you would expect, delays measured in months and years are not uncommon (as I've already pointed out) and it's almost impossible to push your software via regular distribution unless you publish it under open-source license first. The most you can expect is to build your software in form of the package suitable for some Linux distribution (using OpenSUSE Build Service or anything else) and then try to convince people to download your stuff from your server and then manually install it. There exist analogues of the App Stores for Linux (Ubuntu's shop is one example), but these are separate entities and they were brought to this world after rise of Steam and AppStores, not before. And they still are not as easy to use as their counterparts from MacOS/Windows and mobile world (as SDK is still in preview state, e.g.) Well, that's something. It took a decade (Steam is over 10 years old, remember?) for the Linux guys to finally grok the difference between distributions and AppStores, hopefully it'll take less then 10 years to finally catch up with the rest of the world on the availability and usability side. P.S. The really funny thing is that first Linux App Store was created before Steam, but of course everyone derided it and insisted that they don't need anything like that when they have regular Linux distributions where, you know, "community" is in charge, not actual developer of the software. Because, you know, one can not trust developer (which is, ironically, true to some extent, but then developers can only stand so much abuse till they leave… and to offer highest amount of abuse and least lucrative users was not a winning combination).
Why Steam on Linux matters for non-gamers Posted Sep 22, 2013 18:20 UTC (Sun) by lsl (subscriber, #86508) [Link]
> it's almost impossible to push your software via regular distribution unless you publish it under open-source license first.
That, too, is a good thing. Think about it: Why would I make random code part of my product that I can't fix and can't even _look_at_ to determine what it actually does? This is crazy.
Why Steam on Linux matters for non-gamers Posted Sep 22, 2013 19:11 UTC (Sun) by khim (subscriber, #9252) [Link] Why would I make random code part of my product that I can't fix and can't even _look_at_ to determine what it actually does? Why should it be part of your product? Why distribution can not play the role, of, you know, distribution mechanism and give me the ability to install the software I want and bug the author of said software in case of error? Why must everything pass via the distribution's buildfarm? If you don't want to have your good name “tarnished” by such an awful thing as a popular game or a usable CAD then create separate channel (as Ubuntu did). Leave “there should only be FOSS” craziness to gNewSense—at least these guys don't pretend they make something Joe Average can use. I respect these guys as much as Free60 or KolibriO guys: they are creating something they like, they know that what they are creating will never be a mainstream… and they are Ok with that. Fine. That I can understand. But when you create general-purpose operating system why don't you make it, you know, general-purpose?
Why Steam on Linux matters for non-gamers Posted Oct 2, 2013 11:52 UTC (Wed) by krake (subscriber, #55996) [Link]
> IOW: you don't know anything about how distributions work
I obviously don't know about how all distributions work and how everything works for them, but I can definitely make my conclusions based on what I see in those I am monitoring closely enough,
> Sorry to disappoint you, but they don't behave like you would expect, delays measured in months and years are not uncommon
Sorry to disappoint you, but no.
Heck, sometimes the time between tagging (if I am priviledged to that information) and the package availability being announced via automated notification mail is a couple of hours. And that process involves several steps including building, testing and uploading.
> it's almost impossible to push your software via regular distribution unless you publish it under open-source license first
That "almost" must be easily surmountable, in all those years of using various Linux distributions I've installed proprietary software uncountable number of times. The only times when this wasn't available is when the vendor didn't allow redistribution, but then no other form of software repository would be able to distribute it either.
Why Steam on Linux matters for non-gamers Posted Oct 2, 2013 14:12 UTC (Wed) by khim (subscriber, #9252) [Link] My observation is that the time between uploading the package and it appearing on the respective distribution channel is mostly measurable in hours. Sure, but if I'm developer I'm usually is not interested in that time. I'm interested in deploying application to end-user, not to “distribution channel”. Distributions which give you ability to push your update in the stable channels exist (Fedora, for example), but usually you need to wait for the next release, which happens quite infrequently. The only times when this wasn't available is when the vendor didn't allow redistribution, but then no other form of software repository would be able to distribute it either. Why not? Ubuntu does that today. It's relatively new development, of course, but it's perfectly doable.
Why Steam on Linux matters for non-gamers Posted Oct 2, 2013 17:59 UTC (Wed) by krake (subscriber, #55996) [Link]
> I'm interested in deploying application to end-user, not to “distribution channel”.
Well, the time to the channel is the one controlled by a third party. The time to the upload is controlled by the developer, the time from the channel is controlled by the user.
Once the package is available on the channel, the user needs to pull it from there. The factors of that are the user becoming aware of the package and the time needed for download.
The time to awareness will depend on many factors, like whether a user visits the channel regularily (or has that automated) ir whether the channel sends out notifications or whether the vendor sends out notifications.
The distributor can of course influence those, e.g. by restricting bandwidth, but why would they?
> Why not? Ubuntu does that today. It's relatively new development, of course, but it's perfectly doable.
I have no experience with Ubuntu, so just to be sure: you are saying that Canonical shop redirects you to a vendor controlled download server once the purchase is completed?
Why Steam on Linux matters for non-gamers Posted Oct 2, 2013 18:29 UTC (Wed) by khim (subscriber, #9252) [Link] The time to the upload is controlled by the developer, the time from the channel is controlled by the user. Only if user is adventurous enough to play with "unstable" channels. Most users don't want to visit unstable channels which can very well kill their system to receive stable version of software. The distributor can of course influence those, e.g. by restricting bandwidth, but why would they? They are doing for various reasons, but usually new version only pushed to stable "channel" when new stable version of distribution is released. Which may take months if you are lucky or years if you are not. I have no experience with Ubuntu, so just to be sure: you are saying that Canonical shop redirects you to a vendor controlled download server once the purchase is completed? No. It gives you access to the app store which looks like a typical app store, where you only need to grant the right to distribute you application under certain conditions, where you can verify license keys, etc. When Oracle decided to retire Operating System Distributor License for Java Java was removed from Ubuntu store, e.g.
Why Steam on Linux matters for non-gamers Posted Oct 2, 2013 18:54 UTC (Wed) by nybble41 (subscriber, #55106) [Link]
> Only if user is adventurous enough to play with "unstable" channels. Most users don't want to visit unstable channels which can very well kill their system to receive stable version of software.
The "app store" model *is* an "unstable" channel. The point of calling the channel "unstable" isn't that it contains unstable software, but rather that the software hasn't been tested together as part of a stable distribution. Putting your app in an app store and telling users to install from there is no different from putting it in e.g. Debian sid. Either way, you're asking them to install software which may be stable on its own but remains unproven as part of a larger system.
> No. It gives you access to the app store which looks like a typical app store, where you only need to grant the right to distribute you application under certain conditions, where you can verify license keys, etc.
Yeah, I can see why proprietary software vendors might want that, but my impression is that most users of FLOSS operating systems prefer similarly FLOSS applications. We don't want "app stores" selling locked-down proprietary applications which fail to grant essential rights and require things like license keys. That's the sort of thing we switched away from Windows or iOS to avoid.
Why Steam on Linux matters for non-gamers Posted Oct 2, 2013 19:02 UTC (Wed) by krake (subscriber, #55996) [Link]
> Most users don't want to visit unstable channels which can very well kill their system to receive stable version of software.
Multiple channels for different usage scenarious might not be common for app stores yet, or they might handle the different requirements differently, so it is understandable that some of the more traditional channel names lead to wrong conclusions :)
They are not about stability of the software but stability of the version, meaning "unstable" will see faster changes to the version than "stable".
It might help if you think about the levels as terms of updated speeds.
Private end users usually want to have new software fast, so they use the fastest channel.
End users in controlled environments might only have access to some medium speed channel, much like getting operating system updates from a company internal update server so that sysadmins can decide when to clear updates on a case by case basis.
Adminstrators of mission critical systems will usually subscribe to multiple channels, slow ones for non-critical updates, fast ones for critical updates.
The multiple channels are basically an feature previously only available to enterprise customers of large software vendors.
> They are doing for various reasons, but usually new version only pushed to stable "channel" when new stable version of distribution is released.
You are confusing to different things.
You are takling about a service provided to those who prefer controlled update points over getting the most recent release as quickly as possible.
> No. It gives you access to the app store which looks like a typical app store, where you only need to grant the right to distribute you application under certain conditions, where you can verify license keys, etc.
Right, that's what I thought as well. An early comment suggested that the Ubuntu Store and/or other stores could distributed software without requiring the software's vendor to having allowed that.
Why Steam on Linux matters for non-gamers Posted Oct 2, 2013 20:10 UTC (Wed) by khim (subscriber, #9252) [Link] Private end users usually want to have new software fast, so they use the fastest channel. Not really. Users want updates some software fast and most software stable. I don't particularly care if a LibreOffice which I use occasionally to print some documents if up-to-date or not and I certainly don't want to see it changing suddenly (like it did with conditional formatting which made it much harder to use), but for programs which I use frequently and which I want to help develop I want to see latest version available. If I'm software developer this will be a GCC and if I'm crazy painter (sane painters use Photoshop on Mac or Windows) it'll be GIMP. BTW about GCC: I use MSVC 2012 to develop software which is usable on all systems from Windows XP (released dozen of years ago) to Windows 8.1. Can I use GCC 4.8 to develop software usable on Wheezy? Wheezy was released less then half-year ago, right? No? Why the heck no? Wasn't Linux developer tools touted as superior to Microsoft's "junk"? End users in controlled environments might only have access to some medium speed channel, much like getting operating system updates from a company internal update server so that sysadmins can decide when to clear updates on a case by case basis. True. Sysadmins here support Ubuntu 12.04 LTS and Windows 7 (which is older by two years then said version of Ubuntu), but I can use GIMP 2.8 (and aforementioned MSVC 2012) on Windows yet only GIMP 2.6 and GCC 4.6 on Linux. This makes me sad. Very similar to software rollout tools and company internal update servers provided by some operating system software vendors to their enterprise customers, just made available to all customers who want it. What about users who don't want it? You are touting the virtues of this "perfect" model for so long yet I'm still see no instructions which explain how to install GIMP 2.8 on Ubuntu 12.04 LTS. I can probably build it from sources, but, well... distributions were invented exactly to make sure I will not need to do that, right?
Why Steam on Linux matters for non-gamers Posted Oct 3, 2013 2:25 UTC (Thu) by hummassa (subscriber, #307) [Link]
> Can I use GCC 4.8 to develop software usable on Wheezy? Wheezy was released less then half-year ago, right? No?
Ok, let's lay down the pipe.
How come? Hm, khim *must* be right, let's check it, just in case. Get random C program, compile with gcc-4.8 under sid, copy binary to wheezy machine. Works. Ok, copy binary to lenny machine. Still works. Nope. Not right.
Packages.debian.org say that gimp in wheezy is 2.8.
I conclude *I* must be intoxicated, and that I cannot parse you anymore.
Why Steam on Linux matters for non-gamers Posted Oct 3, 2013 2:48 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
well, I wouldn't expect something compiled against the latest version of everything to work against older version.
the correct test would be to compile on Wheezy and try to run the resulting binary on Sid
you can't compile a program with the latest Windows 8 APIs and run it on older versions of Windows either.
If you could always run new software on old systems it would mean that you are not using any new features, which would stop all development
Why Steam on Linux matters for non-gamers Posted Oct 3, 2013 2:59 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
> you can't compile a program with the latest Windows 8 APIs and run it on older versions of Windows either.
Actually, you can do it just fine. As long as you don't use the API in question.
Why Steam on Linux matters for non-gamers Posted Oct 3, 2013 3:21 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
>> you can't compile a program with the latest Windows 8 APIs and run it on older versions of Windows either.
> Actually, you can do it just fine. As long as you don't use the API in question.
while this is technically true, when you compile on a new system, you pull in new versions of libraries (or at least library headers), and so you are going to end up using new versions of the various APIs unless you go to a lot of effort to avoid it (much more effort than just compiling on an older system)
Why Steam on Linux matters for non-gamers Posted Oct 3, 2013 3:34 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
>unless you go to a lot of effort to avoid it (much more effort than just compiling on an older system)
Let me quote this incredible effort to limit APIs to the ones supported by WinXP:
>#define WINVER 0x0501
And that's it. Really.
Now, how can I do this with Ubuntu 13.04? I'd really like my programs compiled against the system glibc work on RHEL6.
Why Steam on Linux matters for non-gamers Posted Oct 3, 2013 3:42 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
you can't have your software that's compiled against the lastest version of all libraries 'just work' against all older versions of libraries.
On windows you may be able to do that for some microsoft controlled libraries because they control everything.
but if you use any third party libraries, you can't just set WINVER and count on it working, because the library version isn't tied to the windows version.
the way to do the equivalent on Linux is to get a set of the headers for whatever version you want to compile against, and use those for your compile, but Ubuntu doesn't provide RHEL libraries any more thatn RHEL provides Slackware libraries.
remember that most of the APIs for RHEL were frozen well before 6.0 was released in 2010, so what you are asking for is even harder than saying that you want something compiled against the 13.04 libraries to work against Ubuntu 10,10 (or more likely 10.04) libraries.
If you want everything for an ecosystem to be controlled by one entity, go get yourself a Mac.
Why Steam on Linux matters for non-gamers Posted Oct 3, 2013 4:00 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
> you can't have your software that's compiled against the lastest version of all libraries 'just work' against all older versions of libraries.
On Windows that works just fine for the core Windows services. Which cover quite a lot of ground - from loading images and UI to network protocols support.
> the way to do the equivalent on Linux is to get a set of the headers for whatever version you want to compile against, and use those for your compile, but Ubuntu doesn't provide RHEL libraries any more thatn RHEL provides Slackware libraries.
Compiling stuff on Windows for older versions of OS? Easy, just set WINVER and maybe a couple of compiler switches. And don't forget to package your libraries. On Mac OS X it's the same (__MAC_OS_X_VERSION_MAX_ALLOWED), except that there's also a standard bundle format.
On stock Linux distributions it's basically impossible. You have to install a parallel environment in a some kind of container.
Why Steam on Linux matters for non-gamers Posted Oct 3, 2013 10:48 UTC (Thu) by khim (subscriber, #9252) [Link] I can package most of the third-party libraries with my application - but I can't package glibc and _everything_ depends on it. And there's no way to say "use symbols that existed in glibc x.y.z". Actually it's possible to do: as I've pointed out earlier LSB solves this problem. What you cannot really do is to use newer version of GCC. Not because of GLibC, but because of libstdc++. Just like GLibC libstdc++ is not designed to be linked into many different modules and it's not forward-compatible. LSB solves tis problem, too - but only up to GCC 4.6 (since libstdc++ is part of GCC you need to modify GCC to solve it, you can not just modify headers and libraries). On stock Linux distributions it's basically impossible. You have to install a parallel environment in a some kind of container. This is valid approach, too.
Why Steam on Linux matters for non-gamers Posted Oct 3, 2013 11:08 UTC (Thu) by hummassa (subscriber, #307) [Link]
> LSB is not supported by Debian
this is incredible BS. LSB 4.1 is supported perfectly by debian, via the installation of the (oooh, surprise) "lsb" package. even packages compiled in Fedora 12 in C++ work if you install the (surprise, again!) "lsb-cxx" package. Just "alien"ate it, install it, voila.
Why Steam on Linux matters for non-gamers Posted Oct 3, 2013 11:46 UTC (Thu) by khim (subscriber, #9252) [Link] LSB is not supported by Debian this is incredible BS. LSB 4.1 is supported perfectly by debian, via the installation of the (oooh, surprise) "lsb" package. That's not support. That's a joke. It reminds me my first experience with Debian many years ago. I've used RedHat back then with a couple of custom PAM modules and wanted to play with Debian. And shiny new (back then) version of Debian supposedly included PAM support. Ok, fine, I've installed Debian and tried this “support”. Can you guess what happened? Right: it was possible to install PAM and get shiny new even packages compiled in Fedora 12 in C++ work if you install the (surprise, again!) "lsb-cxx" package. Sure, you can use it to run some LSB-compatible software (which does not really exist) but can you develop something for Debian using LSB? How will you know which version of LSB to target to support which version of Debian? Where will you find libraries to access APIs not included in LSB (and there are many APIs not included in LSB)? LSB package, yes, it's supported by Debian. LSB development… nope. LSB was developed as a good basis for the hypothetical “Linux distribution's SDK”, but nobody bothered to actually make one. Because it's more-or-less impossible without help from distribution makers and distribution makers are not interested.
Why Steam on Linux matters for non-gamers Posted Oct 3, 2013 13:11 UTC (Thu) by peter-b (subscriber, #66996) [Link]
I'm bored of your excessively frequent, verbose and unnecessarily antagonistic posting. Please desist. *plonk*
Why Steam on Linux matters for non-gamers Posted Oct 6, 2013 12:12 UTC (Sun) by krake (subscriber, #55996) [Link]
> LSB was developed as a good basis for the hypothetical “Linux distribution's SDK”, but nobody bothered to actually make one. Because it's more-or-less impossible without help from distribution makers and distribution makers are not interested.
The problem is not interest of distribution makers, the problem with LSB is that it codifies what RHEL ships at the time of a LSB release.
To be actual useful for both SDK and Application vendors, it would have to specify a situation that distributions would then strive to implement.
I've been to an LSB meeting once. SDK providers asked for a binary compatible update of some libraries for the standard's next(!) version, but the request was turned down because those versions would not be already be available in RHEL at the time of the standard's release.
Why Steam on Linux matters for non-gamers Posted Oct 3, 2013 14:49 UTC (Thu) by jwakely (subscriber, #60262) [Link]
> LSB solves tis problem, too - but only up to GCC 4.6 (since libstdc++ is part of GCC you need to modify GCC to solve it, you can not just modify headers and libraries).
Could you expand on this part please?
What changed after 4.6, and what changes can you make to "fix" it?
Why Steam on Linux matters for non-gamers Posted Oct 3, 2013 16:36 UTC (Thu) by khim (subscriber, #9252) [Link] What changed after 4.6, and what changes can you make to "fix" it? Nothing have changed after 4.6, but as I've said it's a lot of work to support newer version of gcc and Linux Foundation have only done said work for GCC 4.6, not for GCC 4.7 or 4.8 The problem with LSB is that it's tries to solve backward compatibility problem by adding some packages “on the side” which obviously does not work: it's very easy to break compatibility if you are not thinking about it and the only way to make sure it's not broken is to use it. Compare situation with Android SDK, e.g.: Google actually builds things using said SDK which means that if it's broken problems are quickly found and fixed. And if some important APIs are needed then they are added to SDK, too. Distributions don't use LSB to build anything which means that problems with LSB are very low-priority (if they have any priority at all).
Why Steam on Linux matters for non-gamers Posted Oct 4, 2013 14:19 UTC (Fri) by jwakely (subscriber, #60262) [Link]
Gotcha. Thanks.
Why Steam on Linux matters for non-gamers Posted Oct 4, 2013 10:40 UTC (Fri) by nix (subscriber, #2304) [Link]
In theory this could be done; the need for it was identified many years ago, at about the time glibc started using symbol versioning... but it would mean delicate changes to, among other things, GNU ld (and these days gold). Nobody did the work.
Why Steam on Linux matters for non-gamers Posted Oct 6, 2013 12:27 UTC (Sun) by krake (subscriber, #55996) [Link]
> Users want updates some software fast and most software stable.
Yes, but I didn't claim differently. We were talking about the general update rate of the distribution channel, i.e. time between package being released/uploaded and it being available to users.
My guess is that you are somewhat confused by common channel names.
An "unstable" channel reacts almost immediately to package uploads, a "stable" channel updates its package list at pre-determined dates.
The common app stores are all "unstable" channels, there is no coordination between publishing times of packages of different vendors.
> What about users who don't want it?
Channel selection is the user's choice on a private end user's machine, the administrator's choice in a managed setup.
Why Steam on Linux matters for non-gamers Posted Oct 6, 2013 13:07 UTC (Sun) by khim (subscriber, #9252) [Link] We were talking about the general update rate of the distribution channel, i.e. time between package being released/uploaded and it being available to users. I'm not sure what you are talking about, but I'm talking about user experience from one side and developer experience on the other side. User [naturally] does not want to know about channels, update rates and other such things. S/he just wants to play latest Angry Birds or visit some website using Chrome. Developers want to offer some way to make it possible. Everything else are technical details. The common app stores are all "unstable" channels, there is no coordination between publishing times of packages of different vendors. Sure—but this is what users are supposed to use! Last time I've checked Debian's position was that “yes, you can use Debian unstable, but there are no promises”. If users are not supposed to use that thing (except for a brave few) then developers can not use it do deliver their software to the users. With Android or Windows user can decide if s/he wants Beta release or Stable release (even on corporate phone/desktop… well, if developer offers beta at all, of course), while on Linux user can not even use latest stable version! Channel selection is the user's choice on a private end user's machine, the administrator's choice in a managed setup. Do you want to imply that it's perfectly reasonable to install “unstable” on mission-critical server or on CEO desktop? Because it does not look like what Debian project implies from their explanations. All are usually available in parallel, e.g. an IT department can chose to use different channels for different types of machines. Well, that makes sense for the OS, but why should “an IT department” decide what kind of software must be installed there. An IT department decides what should be installed here, of course, but then individual teams decide if they need MSVC 2010 or MSVC 2012, e.g. Note that both of them go on top of Windows 7 because Windows 8 (released almost year ago, remember?) is considered “too new and too risky”. With Linux there are no such choice: either one need to pick “you are on your own” unstable channel or one is stuck with years old programs.
|
|||||||||||||