Pandora's Gui? Will It Even Have One?

[fiori_musicali]

This seems quite negative to me:

You have the attitude of an annoying linux dev. "Users can suck it - only the developer matters! Now shove aside and let me auto-install my crap on YOUR [phone, PC]"

Well, that's fine, but please mark any software you release as "AUTOMATICALLY INSTALLS" so I can stay the hell away from it.

Fair enough, but you did kind of provoke it by trying to "set him straight" about the hierarchy of devs versus users.

If you want to see the fruit of the "We know better than the user" attitude taken to the extreme, read here:
http://developer.pidgin.im/ticket/4986

To be fair, the Pidgin devs were trying to find the medium ground of new feature with user input, but when most of the user input boiled down to "it should be optional because I like to fiddle around with the size" you start to question the sanity of the user.

Well yeah, and no. The debate was essentially about HOW a person "should" use an instant messenger. It seemed to me like the devs' vision was that IM'ing should be to chatting what twitter is to blogging. I consider myself a sane chatter and I love the fact that I can resize the text input field in aMSN according to what the situation requires. I may have to paste in a lot of text and parse it manually for better viewing, or I type in a 30 lines long reply that I want to be able to quickly scan through for errors and check the general coherence of the text. It may sound overblown for IM'ing but here comes the point: The instant messenger is used for communicating with people with whom I don't have other convenient ways to communicate (e-mail is not one of them). It's not up to the Pidgin dev to decide what or how I should communicate. Their position is to provide a flexible, useable interface for the common protocols, not to enforce their own completely arbitrary limitations on that interface because they think they know better than me what exactly I should be using the protocol for. What you have to wonder is the psychological need of the devs to exercise their power regardless of logicality of the actions through which they do that.

To put it into perspective, I think the Pandora should be able to massage my feet, and the fact that it doesn't proves the devs don't care about the user. They could have made it an optional thing.

That's not putting it into "perspective", that's a reductio ad absurdum.

 

[viridior]

Regardless of the who-said-what-to-who-first discussion, and the incorporation of the libpnd thread into this one, the GUI is interchangeable and you will *likely* have to get your hands a little dirty to do this. You *may* have to enter a couple of commands in the command line to use ipkg to install a WM of your choice and edit a text file to set your default configuration. You *may* be able to use PND to accomplish that same thing. I'm sure there will be a wiki entry for each WM that someone decides to use. The devs are providing a platform this allows this to happen easily. There are plenty of linux nerds that would enjoy nothing better then to explain how you can accomplish this feat. It will make you and his's/her's ego happy.

P.S. Bless fiori_musicali for bringing Latin back, that was hawt!

 

[dflemstr]

Dudes, first of all, could all of you just chill? The goal here is to discuss how to make the package installation process as painless and easy as possible for the end user while still having a stable packaging system, and yet there are arguments about things such as elitism, ignorance towards the end user, "pro technica, contra simplicitas", etc. Those discusssions don't seem to be productive in the slightest, and it makes the job of finding actual important parts of the discussion extremely difficult. Please refrain from bickering in this thread from now on so that we can discuss the matter at hand, and continue the flamewar with PMs or not at all. Thank you.

I expected (and am still hoping for) the system to be as in dflemstr's link - it would write symlinks to a UnionFS overlay.

I've been having some problems with dflemstr's idea, though I haven't quite been able to properly put them into a cohesive argument.
For example, what happens if the file already exists? You either go with the PND has higher priority, or you ignore it. Both have pros and cons. If someone releases an unofficial driver update as a PND file, it can just overlay itself over the original and everything just works from there. On the other hand, maybe you want to be able to switch back and forth between the two drivers as needed, or something. Tricky decisions.
And what happens if two PND files overlay the same files, even if they don't already exist? Icon sets, for example. Two packages have, by some coincidence, each placed their icon sets into /usr/icons/newblueicons or something. Need to come up with a good way of resolving these. Possibly a prompt which comes up on mount? Would we want to do it every mount? And how would the prompt go on bootup? hmmm...

I actually thought about that problem, and it seems to me that the best method would be strict versioning of anything that is overlayed. so instead of "lib.so" being overlayed, it would be something like: lib-1-0-5.so.

EDIT: To the uninitiated, please remember that I'm talking about my symlink system here, and not some kind of auto-install-script-that-pollutes-the-pandora. I still don't believe in such a system and am not for one at all. OK?

I don't think that it necessarily is a good idea to allow the "overriding" of files at all. Dependency injection would be a possible exploit if it was allowed, for example (Imagine rewriting libmagic.so and "injecting" (replacing) the original version so that all files are opened by a specific program, for example, or that someone would rewrite libglib.so, thus compromising the whole userspace).

I believe in a more strict rule, that PNDs aren't allowed to "replace" any file in the system, ever, because of the security issues.

Also, since the ld systems in all Linux distributions already have versioning built into them (check your own /usr/lib folder!), that would also allow for something like God Ginrai probably was thinking about; imagine that the file structure on the NAND looks like this (This tree was taken directly from my Arch install, btw):

/usr/lib/
|-- libxml2.so -> libxml2.so.2.7.3                          (symlink)
|-- libxml2.so.2 -> libxml2.so.2.7.3                        (symlink)
`-- libxml2.so.2.7.3

...and a PND for some reason requires a newer version of libxml2.so (let's say, 2.7.5). It would then, when mounted, create a symlink like this:

/usr/lib/
|-- libxml2.so -> libxml2.so.2.7.3                          (symlink)
|-- libxml2.so.2 -> libxml2.so.2.7.3                        (symlink)
|-- libxml2.so.2.7.5 -> /mnt/pnd7273232/libxml2.so          (symlink) <--
`-- libxml2.so.2.7.3

...and applications inside of the PND would of course dynamically link to /usr/lib/libxml2.so.2.7.5, because that's the version they're using.
If and when the "official" NAND firmware then gets the libxml2 version 2.7.5 included, the above will silently transform into this, because PNDs may not override actual NAND files:

/usr/lib/
|-- libxml2.so -> libxml2.so.2.7.5                          (symlink)
|-- libxml2.so.2 -> libxml2.so.2.7.5                        (symlink)
`-- libxml2.so.2.7.5

...and all will be well, plus the PND will benefit from any official optimizations that were done in the official version of libxml2. When version 2.7.5 then becomes out of date, or libxml3 is released, the symlink to the PND version will activate again, and will thus still work, despite the fact that the wrong version of libxml is on the NAND.

/usr/lib/
|-- libxml3.so -> libxml3.so.3.0.0                          (symlink)
|-- libxml3.so.3 -> libxml3.so.3.0.0                        (symlink)
|-- libxml2.so.2.7.5 -> /mnt/pnd7273232/libxml2.so          (symlink) <--
`-- libxml3.so.3.0.0

I am really starting to believe that this could actually work. I'd like to hear WizardStan's comments on it, though, as he seems to have opinions about it still

Oh, and two conflicting packages that both want to "add" the same file? They should be mutually exclusive, and not be allowed to mount at all; that's how all other packaging systems do it.

 

[God Ginrai]

To put it into perspective, I think the Pandora should be able to massage my feet, and the fact that it doesn't proves the devs don't care about the user. They could have made it an optional thing.

That's not putting it into "perspective", that's a reductio ad absurdum.

The reductio ad absurdum still works to prove his point. Many people use the phrase "put into perspective" to mean "so you can see where I'm coming from". A reductio ad absurdum does just that, and therefore he is putting it into "perspective".

EDIT:

I expected (and am still hoping for) the system to be as in dflemstr's link - it would write symlinks to a UnionFS overlay.

I've been having some problems with dflemstr's idea, though I haven't quite been able to properly put them into a cohesive argument.
For example, what happens if the file already exists? You either go with the PND has higher priority, or you ignore it. Both have pros and cons. If someone releases an unofficial driver update as a PND file, it can just overlay itself over the original and everything just works from there. On the other hand, maybe you want to be able to switch back and forth between the two drivers as needed, or something. Tricky decisions.
And what happens if two PND files overlay the same files, even if they don't already exist? Icon sets, for example. Two packages have, by some coincidence, each placed their icon sets into /usr/icons/newblueicons or something. Need to come up with a good way of resolving these. Possibly a prompt which comes up on mount? Would we want to do it every mount? And how would the prompt go on bootup? hmmm...

I actually thought about that problem, and it seems to me that the best method would be strict versioning of anything that is overlayed. so instead of "lib.so" being overlayed, it would be something like: lib-1-0-5.so.

EDIT: To the uninitiated, please remember that I'm talking about my symlink system here, and not some kind of auto-install-script-that-pollutes-the-pandora. I still don't believe in such a system and am not for one at all. OK?

I don't think that it necessarily is a good idea to allow the "overriding" of files at all. Dependency injection would be a possible exploit if it was allowed, for example (Imagine rewriting libmagic.so and "injecting" (replacing) the original version so that all files are opened by a specific program, for example, or that someone would rewrite libglib.so, thus compromising the whole userspace).

I believe in a more strict rule, that PNDs aren't allowed to "replace" any file in the system, ever, because of the security issues.

Also, since the ld systems in all Linux distributions already have versioning built into them (check your own /usr/lib folder!), that would also allow for something like God Ginrai probably was thinking about; imagine that the file structure on the NAND looks like this (This tree was taken directly from my Arch install, btw):

/usr/lib/
|-- libxml2.so -> libxml2.so.2.7.3                          (symlink)
|-- libxml2.so.2 -> libxml2.so.2.7.3                        (symlink)
`-- libxml2.so.2.7.3

...and a PND for some reason requires a newer version of libxml2.so (let's say, 2.7.5). It would then, when mounted, create a symlink like this:

/usr/lib/
|-- libxml2.so -> libxml2.so.2.7.3                          (symlink)
|-- libxml2.so.2 -> libxml2.so.2.7.3                        (symlink)
|-- libxml2.so.2.7.5 -> /mnt/pnd7273232/libxml2.so          (symlink) <--
`-- libxml2.so.2.7.3

...and applications inside of the PND would of course dynamically link to /usr/lib/libxml2.so.2.7.5, because that's the version they're using.
If and when the "official" NAND firmware then gets the libxml2 version 2.7.5 included, the above will silently transform into this, because PNDs may not override actual NAND files:

/usr/lib/
|-- libxml2.so -> libxml2.so.2.7.5                          (symlink)
|-- libxml2.so.2 -> libxml2.so.2.7.5                        (symlink)
`-- libxml2.so.2.7.5

...and all will be well, plus the PND will benefit from any official optimizations that were done in the official version of libxml2. When version 2.7.5 then becomes out of date, or libxml3 is released, the symlink to the PND version will activate again, and will thus still work, despite the fact that the wrong version of libxml is on the NAND.

/usr/lib/
|-- libxml3.so -> libxml3.so.3.0.0                          (symlink)
|-- libxml3.so.3 -> libxml3.so.3.0.0                        (symlink)
|-- libxml2.so.2.7.5 -> /mnt/pnd7273232/libxml2.so          (symlink) <--
`-- libxml3.so.3.0.0

I am really starting to believe that this could actually work. I'd like to hear WizardStan's comments on it, though, as he seems to have opinions about it still

Oh, and two conflicting packages that both want to "add" the same file? They should be mutually exclusive, and not be allowed to mount at all; that's how all other packaging systems do it.

That's exactly what I was talking about. This system really seems like it would work well. ^_^

-God Ginrai

 

[fiori_musicali]

The reductio ad absurdum still works to prove his point. Many people use the phrase "put into perspective" to mean "so you can see where I'm coming from". A reductio ad absurdum does just that, and therefore he is putting it into "perspective".

To "put it in the perspective" means to set it in the correct context, to draw proportions, which is exactly what the analogy avoided. A small but relevant bit of trivia to know in this argument is that the Pidgin devs removed a feature that existed. I didn't realize Pandora came with a foot massager, put it back or I'll cancel my order!

But I'll comply with what dflemstr suggested and refrain from further off-topic bickering.

 

[viridior]

Since this thread seems to have converted to a libpnd discussion with no revert in sight, I'll continue with the herd.

The only technical issue I have with PND (which I actually like) is that if you progress this through a year or two of linux development, many of your support libraries will change. At some point, a few of them will go through a major version change and break backwards compatbility. This logic then suggests that you either:
1. Have to assume that everyone has a pandora-angstrom-OS-1.0 (the initial official OS) software library and each .pnd will have to include all of the library upgrades necessary to run whatever program it represents.
2. Restrict software bundled to .pnd to those that don't drastically need to modify the OS.
3. A hybrid of 1 & 2
4. Each .pnd has a built in "OS version" checker and therefore is only compatible to that and higher.
5. 3 & 4

This is not a trivial issue because a few of the low-level GNU programs and a few more of the xorg-server programs are inter-dependant on each other and are upgraded simultaneously in order to maintain compatibility with each other but not necessarily backwards compatibility.

Thoughts?

 

[WizardStan]

Well yeah, and no. The debate was essentially about HOW a person "should" use an instant messenger. It seemed to me like the devs' vision was that IM'ing should be to chatting what twitter is to blogging. I consider myself a sane chatter and I love the fact that I can resize the text input field in aMSN according to what the situation requires. I may have to paste in a lot of text and parse it manually for better viewing, or I type in a 30 lines long reply that I want to be able to quickly scan through for errors and check the general coherence of the text. It may sound overblown for IM'ing but here comes the point: The instant messenger is used for communicating with people with whom I don't have other convenient ways to communicate (e-mail is not one of them). It's not up to the Pidgin dev to decide what or how I should communicate. Their position is to provide a flexible, useable interface for the common protocols, not to enforce their own completely arbitrary limitations on that interface because they think they know better than me what exactly I should be using the protocol for. What you have to wonder is the psychological need of the devs to exercise their power regardless of logicality of the actions through which they do that.

The devs said "this sounds like a great idea" and they implemented it. And it was a great idea, which solved a lot of use cases. When users complained, they accepted that their idea wasn't perfect, and went about trying to make it so. The conversation basically went "ok, tell us how you use it, we can work out some kind of compromise that makes everything work for everybody" to which the response was "no, make it an option to do it the old way!" The devs then responded "that would mean maintaining two code bases for the same basic functionality. If you can provide a good use case for why you want this, and we can't find a way to merge the two, then we will." To which the responses were "I shouldn't have to justify myself to you" and "I want it because I want it!"
At which point in time, if I were a Pidgin dev, I would have implemented the "min/max" suggestion that was made (and then rejected by some of the users because they just wanted an option to go back to the old way) and added an "option" to turn off autosizing which didn't actually do anything except set min and max to the same value. To the user it looks the same. Sometimes the developer does know better than the user.
But they didn't. As far as I know, the bickering is still ongoing.
If they had refused to fix things outright, I would agree with you 100%, but they were trying to work with the users to figure out exactly how to fix things; it was the users themselves who were trying to force their beliefs on the developers, not the other way around. Another example was even given: removing the "send" button in favour of just pressing the enter key. Someone complained that it didn't work for their use case, they worked together, and found an option which worked perfectly for everyone.
Progress requires changing features, and sometimes those changes don't work for everyone. When that happens, we can either revert the feature, or work together to figure out what was wrong with the feature and try to make it better.

To put it into perspective, I think the Pandora should be able to massage my feet, and the fact that it doesn't proves the devs don't care about the user. They could have made it an optional thing.

That's not putting it into "perspective", that's a reductio ad absurdum.

Yes, it was ridiculous, and that was the point. When the users make demands and then refuse to justify them and work with the developers, it isn't the developers fault when those demands go unheeded. As you said, the Pandora needs a unified community, and that means the users and developers working together, not the users making a feature request and expecting it to go in unquestioned.


edit:

To "put it in the perspective" means to set it in the correct context, to draw proportions, which is exactly what the analogy avoided. A small but relevant bit of trivia to know in this argument is that the Pidgin devs removed a feature that existed. I didn't realize Pandora came with a foot massager, put it back or I'll cancel my order!

*retroactively changes the phrasing to say "to provide an extreme example that should help illustrate my point"*

edit 2: because apparently I don't always finish my sentences