On Wed, 12 Oct 2011 22:07:04 -0600, Bob Proulx wrote: > Camaleón wrote: >> Bob Proulx wrote: >> > Camaleón wrote: >> >> Besides, I'm sure you know that flash player plugin can contact you >> >> webcam and audio devices very easily. >> > >> > Is that true on an ARM based platform? Remember that Debian supports >> > a large number of architectures. AFAIK there is no Adobe Flash >> > available for ARM based systems. >> >> And what has ARM to do with this? Are you running an ARM based machine? >> Yes? Then good for you :-) But people running flash player on their >> systems are subject to that type of scannings. > > Yes, an ARM machine. And I picked that one because there is no Adobe > Flash for ARM.
Again, I selected Flash player as an example of what can be done through a web browser. HTML5 was another example I used. If you don't like this specific example (although it seems that ARM already supports Flash Player¹), you can rename "flash player" by "java" or whatever plugin you prefer. >> > Is that true with Gnash (GNU Flash)? Gnash is the only flash player >> > on my main desktop (although other machines of mine have the Adobe >> > proprietary player). (Although I mentioned ARM above my main desktop >> > is amd64. I didn't want to be misleading here. But I do have ARM >> > based systems.) >> >> Good, but again, are we talking about "you" specifically or we are >> taking a more wide user case? > > I am talking about "Debian". This is a Debian mailing list. Debian > supports many architectures and not just 32-bit x86. Are we talking > about "you" specifically here running a 32-bit x86 architecture and able > to run Adobe Flash? :-) But this is not about "Debian" but "bug reporting" for Debian. And reporting bugs can happen on any platform. You can be running Debian but having the system at a completely unbootable stage nd you need to report a bug in a windows/macos/solaris machine... what to do then if reportbug is not available under those systems? Manually gather the required data and write an e-mail? I'd say "interoperability" is the key for a Bugzilla-alike reporting system. Interoperability and "standarization" between projects because Bugzilla is a very well-known platform in other open source projects so for users who were already used to that system, the learning curve will be "zero" when they have to report in Debian. >> I am telling you what happens right now with technology that is >> available in our systems, I can't speak for every concrete desktop >> there is on the earth as you can understand... > > I am talking about mainstream Debian systems. Debian has been called > the Universal Operating System for good reason. It runs on many > different architectures. Here is the official list. > > http://www.debian.org/ports/ > > Debian is all about free(dom) software and the Social Contract and the > DFSG (Debian Free Software Guidelines) reflect this. If you have the > source code then you are not limited to a proprietary blob limiting you > to a specific architecture. If you have the source code then you are > free to run on whatever architecture you have available. This is a core > point of Debian and one that makes it "Outstanding". :-) Good. You have given me more arguments... Do you know something more open, universal and flexible than the web and its protocols? In what way is Bugzilla reporting tool -or similar applications- limiting any of the above, being also "open source"? ;-) >> To be sincere, I don't care about flash player very much, just put it >> as an example of what can be done with a small plugin and a browser. > > "Small" plugin? Maybe. (At 134K I think that is quite large.) But it > certainly has been a big problem for a long time. In any case it is a > good example of a bad example. It's very small for what it provides. It's about ~20 MiB of size in my system, though. And for the "bad example", well, that's your personal opinion. I was not referring about its quality nor its code, but I find is a perfect example for an addon and its current capabilities. One thing is that we don't like Flash Player and another thing is neglecting its capabilities. >> Bugzilla (and related web based bug tracking systems) also provides >> wizards which guide the user to write the report. It's the same as >> reportbug, you can customize the level of help you want to receive and >> set that level as the default for the next time. > > To be clear I have never opposed having a web interface to submit bugs > to the BTS. I however think the best part of the BTS is the ability to > use email to interface to it. Email is so simple and pervasive that I > can't see ever wanting to use any other method. Maybe you did not read well what I said before. I wouldn't like to see reportbug dissapearing nor losing the possibility to send bug reports by e-mail , that would be terrible. What I said is I would like to have *an alternative* way for bug reporting. You like reportbug? You use it. You like the http interface? You use it. You like plain based e-mails? You write them. It's all about possibilities. >> > But I disagree completely here that a web browser filling in a web >> > form has access to the local system as it is intended to be >> > impossible by design and security layers to run local programs across >> > the local filesystem as a web form. Note that Javascript runs inside >> > a security layer and is restricted from this access. >> >> Oh, come on, is not that hard. In the worst scenario, you can tell the >> user to download a script with instructions to run it and then send the >> output to a file to be uploaded with the report. > > I think that would be teaching users bad habits. Most users are not > well versed on the details of verifying trust paths from scripts > downloaded from the Internet. Why "bad habits"? That's nonsense, you are instructing users how to deal with command line and scripts :-) What indeed is a "bad habit" is sending extra information about your system when you only want to open a "wishlist" report, for example. You are gratuitously exposing data that is not useful for the bug report and you could be sending sensitive information of the user system. >> That's all. It's possible, easy and convenient for the user that can >> run the script when he/she wants and attach it to the bug later, when >> there is Internet connection, for example. > > So... There could be a script on the web site. The user could download > the script and run it. That script could be called something like > "reportbug"? :-) Nope, reportbug does not run specific tests, it's a generic app to generate and track (somehow) bug reports. >> > Try moving it out of the way and running without local customization. >> > >> > $ mv ~/.reportbugrc reportbugrc.suspect $ reportbug -b somepackage >> >> I had to not only remove that config file several times but also set >> "ncurses" GUI as the default to avoid perpetual crashes... > > Does that mean that when you were experiencing crashes you were using a > graphical GUI interface? Yes, the GUI crashed more often than ncurses. > If so then that is not the default and must have been customized that > way. If so then that explains the problem. You mean the GUI interface is known to be problematic? > I dare say that people like me who have never experienced a crash are > using 'reportbug' in the default configuration and those that are > complaining about it crashing have turned on some GUI interface. There > appears to be one. I have never used it. It is not the default > setting. I didn't even know it existed until a moment ago. Then you should launch it from time to time and see how/if it works for you ;-). The GUI is an option and it's indeed _the default_ when you launch reportbug from the GNOME menu ("reportbug --exit-prompt --ui gtk2"). ¹http://www.arm.com/about/newsroom/26062.php Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.10.13.13.57...@gmail.com