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. > > 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? :-) > 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". :-) > 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. > 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. > > 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. > 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"? :-) > > 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? If so then that is not the default and must have been customized that way. If so then that explains the problem. 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. Bob
Attachment:
signature.asc
Description: Digital signature