Positions forming in the Debian init system discussion
Positions forming in the Debian init system discussion
Posted Jan 2, 2014 2:58 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)In reply to: Positions forming in the Debian init system discussion by krake
Parent article: Positions forming in the Debian init system discussion
1) More 'regular' windows managers. Exotic window managers like ratpoison are fine - they were not designed for regular users.
2) More music players.
3) More Internet browsers that nobody uses.
Posted Jan 2, 2014 17:14 UTC (Thu)
by krake (guest, #55996)
[Link] (11 responses)
Just like in any other product categeory, nothing special regarding computing in general or Linux specifically.
Sure, there are always users that like to evaluate the unknown, but then that is their prerogative.
Most people settle for a given product option and only reevaluate if that option no longer fits their needs, e.g. their needs changed or the product changed, etc.
However, the same person can apply different behavior to different kinds of product, e.g. changing car model every time but staying with the brand, or keeping the same product of shampoo even when the vendor changes, etc.
Posted Jan 2, 2014 17:43 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (10 responses)
Actually, there is. Linux in many cases Just Doesn't Work (tm) and consumers simply vote with their feet.
Posted Jan 2, 2014 19:22 UTC (Thu)
by krake (guest, #55996)
[Link] (9 responses)
No. Every product category has multiple options to chose from. Even when manufacturers have consolidated down to a handful worldwide.
> Linux in many cases Just Doesn't Work (tm)
Awww. You have to try better (tm). Nobody on lwn.net will fall for such primitive flamebait.
> consumers simply vote with their feet.
Exactly! Hence no need to artifically curb availability. A new music player will not gain any users if does not appeal to some. If it does they will, as you put it, vote with their feet and use it instead of whatever they used before.
A couple of years ago most music players were like WinAMP. Luckily there was no artifical ban on new music players so nowadays most use softwarethat is more like a music library.
Posted Jan 2, 2014 19:39 UTC (Thu)
by raven667 (subscriber, #5198)
[Link] (8 responses)
Posted Jan 2, 2014 19:57 UTC (Thu)
by dlang (guest, #313)
[Link] (6 responses)
Many of us think that competition is very useful in infrastructure and standardization provides real benefits in end user applications.
we are looking for standardization in file formats and APIs, not in limiting the number of possible options.
Posted Jan 2, 2014 20:26 UTC (Thu)
by krake (guest, #55996)
[Link]
Posted Jan 2, 2014 20:32 UTC (Thu)
by raven667 (subscriber, #5198)
[Link] (4 responses)
Posted Jan 2, 2014 21:26 UTC (Thu)
by dlang (guest, #313)
[Link] (3 responses)
the API relevant to those applications is X11 for display. The fact that different apps use different toolkits to talk to that API is not a big deal (as long as the toolkits are willing to co-exist, which they are)
There are a lot of infrastructure components in *nix that have changed significantly over time (look at the capabilities of rsyslog v7 vs sysklogd for example), but the applications using them don't need to know about the differences between them if they don't want to.
similarly, the login process has changed radically since the early days, but because the APIs have been stable, the changes in details (from /etc/passwd to /etc/shadow to PAM) haven't required app changes.
Posted Jan 3, 2014 15:29 UTC (Fri)
by torquay (guest, #92428)
[Link] (2 responses)
I'd argue that while having a low-level API like X11 is useful, it would be even more useful to have a standardised toolkit API, which exists at a higher level (ie. less verbose) and is hence easier to program in. One can of course change the look + etc, through re-implementing the API, but not breaking it. Standardisation at a higher level can be applied to many other parts of the stack.
The main point is to draw a line of standardisation (and hence stability) somewhere in the overall stack, in order to achieve a sweet spot between 2 factors: customisability and ease of use, both from the point of view of writing end user applications. End user applications and users are the entire reason operating systems exist in the first place -- many people in the open source world seem to forget this.
Right now the trade-off between the 2 factors is completely out of whack. The only thing that's standardised in the Linux world is the kernel, glibc and to a large extent the mess that's X11. In almost everywhere else though, we have lots of customisability along with associated costs of piss poor API stability. GTK is still a moving target (deprecating and adding APIs at an uncomfortable rate). Qt is a bit better, but it has gone through many major releases in a relatively short span.
Enough is enough. Any efforts to standardise low-level plumbing though software such as systemd are very welcome.
It is of course pertinent to note that there is already one Linux-based system which has taken stability seriously: Android. It's also relevant to note that the number of tablets and phones running Android easily eclipses the "traditional" Linux desktop.
Posted Jan 4, 2014 15:38 UTC (Sat)
by krake (guest, #55996)
[Link] (1 responses)
Sure, but developers would most often still use the toolkit they prefer.
Motif was basically the standard toolkit for X11 based systems, yet most developers use GTK+ or Qt.
Speaking of Qt, a large portion of Qt developers use Qt on Windows, which presumably has a standard toolkit.
Even single vendor solutions need to change toolkits now and then, but just like on X11 the common low level API makes it possible to keep old and new API working in parallel.
Standardisation of APIs is unfortunately often also just wasted effort. Standardisation of protocols and data formats on the other hand are usually long lived and successful.
Posted Jan 4, 2014 23:23 UTC (Sat)
by dlang (guest, #313)
[Link]
actually, I'll disagree with this.
standardization of APIs can be extremely valuable
standardization of toolkits (and their APIS) is far less useful.
The Unix POSIX API standardization is an example of a very valuable API standard.
Posted Jan 2, 2014 20:25 UTC (Thu)
by krake (guest, #55996)
[Link]
I mentioned music players as an example because that is one of the examples in the grand grand parent comment.
There is competition in this area, as you said, and it has been proven useful (change in needs of music players, avoiding IE-only stagnation, etc)
Positions forming in the Debian init system discussion
Positions forming in the Debian init system discussion
Positions forming in the Debian init system discussion
For some kinds of products the availability of options is so important that single manufacturers even have "competing" products under different brand names.
Positions forming in the Debian init system discussion
Positions forming in the Debian init system discussion
Positions forming in the Debian init system discussion
Positions forming in the Debian init system discussion
Positions forming in the Debian init system discussion
Positions forming in the Debian init system discussion
the API relevant to those applications is X11 for display. The fact that different apps use different toolkits to talk to that API is not a big deal (as long as the toolkits are willing to co-exist, which they are)
Positions forming in the Debian init system discussion
Positions forming in the Debian init system discussion
Positions forming in the Debian init system discussion
