| |||||||||||||
Why Steam on Linux matters for non-gamersWhy Steam on Linux matters for non-gamersPosted Sep 22, 2013 16:36 UTC (Sun) by khim (subscriber, #9252)In reply to: Why Steam on Linux matters for non-gamers by krake Parent article: Why Steam on Linux matters for non-gamers
> Really? News to me. Have you actually checked what happens in real world, or do you want to discuss some imaginary alternate reality? Simple check: GIMP (very popular image manipulation program) and Ubuntu (one of the most popular Linux distributions). If you use latest LTS version you are stuck with GIMP 2.6.12 (released 1.5 years ago), if you use latest stable version of Ubuntu you are stuck with GIMP 2.8.4 (released over half-year ago), only if you pick unstable and unfinished version of Ubuntu you finally get GIMP 2.8.6 (which is latest stable version of GIMP). Can we please, discuss realities of this world, not your fantasies? All app stores I had observed so far did require pre-packaging, i.e. only allowed uploads of packages, making them equivalent to distributions repostories which also require the same packaing step. Well, sure. How else this stuff is supposed to work? Even worse, I had experienced situations where some target platforms required packaging even for local testing! This may not be very convenient, but I don't see what's so problematic about that. The only system that improved on that which I knew about was the OpenSUSE Build Service, which takes care of packaging and distribution and thus, as you said, only puts very limited obstacles between developers and users. OpenSUSE Build Service really solves minor and mostly unimportant part of the problem. Really hard stuff happens before building and packaging (when developer need to actually write that stuff, you know) and after packaging (when Q&A must test the result and it must be delivered somehow to the end user). It's not a bad software, but it does not even try solve the distribution problem: for the distribution channel to work it must come pre-installed with your OS (or it must be promoted heavily like Amazon's AppStore) and AFAICS the OpenSUSE Build Service does not even have an UI for that. With Google Play you reach half-billion of users or so, with Apple's App Store you reach two million premium users (the most lucrative ones) or so, even with Samsung's Store or Amazon's Store you reach hundred of million users or so. Who do you reach if you pick OpenSUSE Build Service? And how?
(Log in to post comments)
Why Steam on Linux matters for non-gamers Posted Oct 2, 2013 12:11 UTC (Wed) by krake (subscriber, #55996) [Link]
> Have you actually checked what happens in real world
Yes I have and I do. Almost daily. email notifications can be a handy thing.
> Can we please, discuss realities of this world, not your fantasies?
That's what I do, but we can discuss your fantasies if you prefer.
For example, in order to discuss the situation for the GIMP packages, can you provide the datetimes of their upload and those of their respective appearance on their distribution channel?
I am unfortunately neither monitoring GIMP nor Ubuntu so I lack data on when the packages were uploaded into the package-in-queue and when the packages appeared in the repository they were uploaded to.
> Well, sure. How else this stuff is supposed to work?
Don't ask me. Your previous comment seem to indicate that app stores somehow did not require any packaging before uploading while Linux repositories did. Hence me being positively surprised since it wasn't what I had heared and withnessed so far.
> This may not be very convenient, but I don't see what's so problematic about that.
I didn't claim it was problematic, I just personally find it highly inconvenient given the alternatives on systems that do not require that.
> OpenSUSE Build Service really solves minor and mostly unimportant part of the problem
Maybe. It was just the only thing that came to my mind that had the properties of what you seemed to describe, i.e. not requiring any packaging as part of the upload process.
It is of course not relevant for the discussion if none of the app stores allow you to do that either.
Why Steam on Linux matters for non-gamers Posted Oct 2, 2013 14:33 UTC (Wed) by khim (subscriber, #9252) [Link] For example, in order to discuss the situation for the GIMP packages, can you provide the datetimes of their upload and those of their respective appearance on their distribution channel? GIMP 2.8 was added to Debian “Tue, 08 May 2012”. It become available to Debian users “Tue, 04 May 2013” (when Wheezy was finally released). That's almost the whole year! And it's not available in Ubuntu LTS till today. I am unfortunately neither monitoring GIMP nor Ubuntu so I lack data on when the packages were uploaded into the package-in-queue and when the packages appeared in the repository they were uploaded to. Why are interested in this time? Sure, that time is measured in hours, but end-users don't see the package for months and years. And if I'm developer I'm usually interested in the last one: what does it change for me if it's available in some obscure place or not if users don't see it and can't use it? It is of course not relevant for the discussion if none of the app stores allow you to do that either. The important property of app stores is emulation of regular stores. App developer determines the date when software is available (it must be submitted in advance if review process is involved but even Apple allows you to pick the exact time when reviewed and approved app will be available to the end user), end user determines when s/he wants to upgrade it (or install for the first time). Distributions reserve all the timing rights to themselves: developer can not affect this time at all and user should either update everything or nothing. Not cool. Not cool at all.
Why Steam on Linux matters for non-gamers Posted Oct 2, 2013 18:33 UTC (Wed) by krake (subscriber, #55996) [Link]
> GIMP 2.8 was added to Debian “Tue, 08 May 2012”
Added as in uploaded or added as becoming part of the repository?
> It become available to Debian users “Tue, 04 May 2013”
That would suggest that the first of the two dates was the upload date, not the date when it added to the Debian package repository, however
> when Wheezy was finally released
suggest that the second date is a Debian release date, which makes is highly unlikely that it is also the date of the package being added to the repository (nobody adds new packages on the day of release).
So from those pieces I gather that GIMP 2.8 appeared in the Debian package respository on Tue, 08 May 2012.
According to Wikipedia that version was released on Thu,03 May 2012.
So assuming a fully ready, packaged and tested, GIMP was uploaded on that day, then it took 5 days for the package to become available.
> Why are interested in this time?
It is the only time that is added by the app store or repository provider. All time before that is controlled by the software vendor, all time after that is controlled by the person or automated system installing the software.
> Sure, that time is measured in hours, but end-users don't see the package for months and years
So we are talking about user who neither use automated update checking nor manually open the store frontend or have it confgured to not download new package lists on open?
The only app store that I have experience with that works differently is the PlayStation store, which displayes new games in some kind of overlay when the user idles in the main menu. Neither Nokia's Ovi Store, nor BlackBerry's AppWorld ever did that on my devices.
> App developer determines the date when software is available
Specifying a later date, as in wait for a certain date even if approved earlier, is the only difference that I can see.
I wonder if anyone has ever approached any Linux distributor with a request for that and if, why they decided not to add that capability.
Why Steam on Linux matters for non-gamers Posted Oct 2, 2013 20:10 UTC (Wed) by khim (subscriber, #9252) [Link] Added as in uploaded or added as becoming part of the repository? Does it really matter? That's the date from GIMP's package changelog and I don't care about few days. Years - yes, that I do care about. So assuming a fully ready, packaged and tested, GIMP was uploaded on that day, then it took 5 days for the package to become available. You have very strange definition of "available package". To me it's very simple: package is available when it's available. That is: when I can actually use it. If I start package manager, appstore application or appstore's website and can not click "Install" (or "Upgrade") then package is not available. Believe me: most users have this exact definition of package availability. Remember? Simple things should be simple, complex things should be possible. You want to skip the first part and talk only about second one, but in reality first part is more important! All time before that is controlled by the software vendor, all time after that is controlled by the person or automated system installing the software. Ok, perhaps I'm missing something obvious. Let's consider one simple example. My needs are simple: I want to develop software usable on Ubuntu Lucid 12.04 LTS and use GIMP 2.8 to edit my photos. What should I do to achieve that? So we are talking about user who neither use automated update checking nor manually open the store frontend or have it confgured to not download new package lists on open? We are talking about “Joe Average” use. The one who never installs new OS (when it's broken beyond repair s/he calls the support who will do a new installation for a fee) yet wants to use couple of recently released programs (you know: games, may be some photo editing software like GIMP). I can be “Joe Average” user with Android or Windows (to some degree), but on Linux I get only “features previously only available to enterprise customers of large software vendors”. Sorry, but I neither need them nor want them. My needs are simple and they are not met.
Why Steam on Linux matters for non-gamers Posted Oct 3, 2013 2:27 UTC (Thu) by hummassa (subscriber, #307) [Link]
> My needs are simple and they are not met.
You *do* get that this site's name stands for "Linux Weekly News", don't you? If linux does not meets your needs, are you here just for the trolling factor?
Why Steam on Linux matters for non-gamers Posted Oct 3, 2013 10:56 UTC (Thu) by khim (subscriber, #9252) [Link] Who's trolling whom? There are at least two versions of Linux which can be used by “Joe Average”. Sadly they both can not be used to develop software and lack decent graphic editor. So by now it's a race: either one of these will receive things needed for development and serious work or other Linux versions will get their act together. Sadly it looks like the first will happen and we'll be faced with the need for another “careful examination” like already discussed one.
Why Steam on Linux matters for non-gamers Posted Oct 4, 2013 10:45 UTC (Fri) by nix (subscriber, #2304) [Link]
You appear to believe that software which is available in Debian testing is not "available". This is... inaccurate. It is easily available from anywhere on Earth with a network connection.
Your plaint appears to be that you want software to appear instantly in LTS releases of distributions (RHEL, Debian stable, Ubuntu LTS...). Well, guess what, the long-term-support releases are called that because they are *stable*. They are stable because they *do not change unnecessarily*. Massive backports of everything everyone ever wants into LTS releases would make them not LTS releases anymore.
Why Steam on Linux matters for non-gamers Posted Oct 4, 2013 15:31 UTC (Fri) by raven667 (subscriber, #5198) [Link]
I think the point though, one that I agree with, is that "stability" in an LTS release is more useful if it refers to ABI stability, so that software installed on it continues to work, and not the stability of never having anything change. The example of the GIMP is a good one because it is a leaf node of any dependency graph, there shouldn't be any dependency hell problem running newer version on the same ABI level of your LTS release.
To have the system work like this though requires a commitment to ABI stability that at this time can only be assured by never changing any libraries or applications, it would require re-defining the system in terms of a core and a GUI and applications with ABI guarantees between the layers, rather than the unlayered system we have now where everything tracks a full dependency graph to everything else.
I'm not sure I'm explaining my thoughts very well, I might need more coffee yet 8-)
Why Steam on Linux matters for non-gamers Posted Oct 6, 2013 12:55 UTC (Sun) by krake (subscriber, #55996) [Link]
> Does it really matter?
Of course it does if the discussion's topic is time needed for a certain step in chain of events. The time required for the step is determined by the start time and the end time, so it really matters a lot which one we are looking at because one needs to find the other one.
In this case the time given was the end time, so missing one was the start time, which was approximated to be about 5 days earlier.
> You have very strange definition of "available package". To me it's very simple: package is available when it's available.
That is exactly my definition as well.
It is then reported as available to the user running the update request.
> That is: when I can actually use it.
The time between the software becoming available and you using it is totally up to you. There is no difference between any forms of software distribution, even for software pressed onto CDs this time is your choice and your choice only.
> We are talking about “Joe Average” use.
I had assumed as much, but your comment about users not seeing updates for months or years threw me off. The only way that to happen is the user having turned off automatic updates and never checking for updates manually.
I certainly know about users that do not check for updates manually and have automatic updates turned off, but I am afraid no distribution method in the world would make them see new versions.
Any user who does check for updates or has that delegated to some automated process will see changes if there have been any.
The example with GIMP 2.8 on Debian shows that a user who checks for updates daily would not see the update for five days after release by the software vendor.
I agree that this is not very fast, but probably acceptable for most users unless they have been waiting impatiently for exactly that release to happen.
> I can be “Joe Average” user with Android or Windows (to some degree), but on Linux I get only “features previously only available to enterprise customers of large software vendors”.
Actually on Linux (at least most disitributions) you have the choice.
Why Steam on Linux matters for non-gamers Posted Oct 6, 2013 13:34 UTC (Sun) by khim (subscriber, #9252) [Link] You can subscribe to enterprise channels, often without extra cost. It is not something you have to do. Actually that's something you obviously need to do. If you are “Joe Average”, that is. Remember: today's “Joe Average” does not know about existence of command line (Ok, Ok, Ok, this may be overstatement: many of them actually know that such thing actually exist, but very few of them ever seen it) and have only vague understanding of configuration knobs available in GUI. You may ask: how can s/he survive in Windows world where such things are also sometimes needed? Well, that's easy: they are doing this under guide from others. On the west it's usually done by the computer vendors (who will automatically refuse to deal with you if you ever mention the fact that you've used some other version of OS then what was preinstalled), while in the east it's separate firms (one, two, three—this makes them somewhat more flexible because they can install different versions of OS, but again if user reinstalled OS then warranty is null and void). The gist of the situation is the same in all cases: every time you need to go to command line and/or need to change a config file it's a big problem and it's really expensive for you. If that happens on the few computers in your firm it's a disaster (and may be significantly more expensive then just payment for the “computer master”). Do you still want to imply that it's safe for such a user to switch to unstable channel to receive latest stable version of GIMP? I was under impression that it does not work that way. I had assumed as much, but your comment about users not seeing updates for months or years threw me off. The only way that to happen is the user having turned off automatic updates and never checking for updates manually. The one way for that to happen is to have OS (installed by “computer master”, not by user, remember?) tuned to “stable channel”. And I kind of assumed that it's the default setting (at least it was the default setting in all companies, schools and other places where I've seen Linux in use). Do you want to imply that you have stats which show that users actually use “unstable channel” en masse?
|
|||||||||||||