Leaderboard

I think we all hate them. I especially hate Google's since I learned that Google is using reCaptcha challenges to train its AI. If they want me to work for them, I think they should pay me.... Which site / captcha is giving you trouble? JFYI, Serpent 55 has no problem with Google's reCaptcha demo page at https://www.google.com/recaptcha/api2/demo with the user agent overridden to Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.9) Gecko/20100101 Firefox/60.9.

Another important point is how fingerprinted your browser is. They say reCaptchas also let you pass without any probs in other browsers if you're logged into a Google account... Good point! Suddenly it makes perfect sense that many images are so confusing, with no clear answer! Am afraid they abuse all their services to train their almighty AI. After recent reports about AI now being able to even do fake phone calls, sounding like real people and asking+replying intelligently, and getting away as real humans, there seem no limits anymore. And for example knowing how the internet is infested with paid trolls and spammers, pretending to be regular users and trying to distort public opinions, one can bet they now continually replace those fake accounts with AI robots too :-/

not absurd if they do it on purpose ... if they made a "perfectly good OS" they nobody would ever upgrade to next one

I think we all hate captchas. I especially hate Google's reCaptcha for the reason I gave above. Google's reCaptcha is used by many Web sites, but the data is hosted by Google, and your responses are validated by Google. They sneak a few images into their reCaptchas where the "correct" answer is unknown, so they can use the user's responses to train their self-driving car software. I don't even mind Google developing self-driving car software; I wish them the best of luck in that. I just resent being dragooned into helping them develop it, just to use a Web page. I don't hate everything about Google; I still use their search engine (albeit via Startpage.com).

That was my attempt awhile back to figure out if engine is gecko or goanna, for a K-Meleon macro: _troubleshootprefs_getKMver{ if ((getpref(STRING,"platform.name")=="Goanna") or (index(getpref(STRING,"services.sync.syncKeyHelpURL"),"palemoon")>0) or (index(getpref(STRING,"services.sync.addons.trustedSourceHostnames"),"palemoon")>0)) $_eng="Goanna"; else $_eng="Gecko";

alright renamed to foxyproxy_standard-4.6.5-pm.xpi okay it will check app.feedback.baseURL as well if palemoon is not found in browser.search.searchEnginesURL.

No need to apologize , though what I actually meant is still slightly different. Mass Storage connection makes sense for a mass storage device and (by convention) this implies on Windows that a drive letter is assigned to volumes on it, but this drive letter assignment is the result of the way Windows works because it has access to the PhysicalDrive and - via mount manager - to logical volumes (what get a drive letter) and their filesystems. The (stupid) PTP/MTP approach is at a higher level and never provided drive letters because it has no connection to the physical drive, and what I was lamenting about was not the lack of drive letter access but rather the lack of the more direct access that allows otherwise (besides other possibilities) "normal" drive letter access. A good example of a similar approach is FTP, you have NO idea when you connect to a FTP site/directory what OS is running "there", nor which filesystem you are actually accessing. Still you have exposed some file characteristics, like (usually) size and date. If you take (on a "recent") window a ftp site you can map it to a drive (drive letter) just fine, *like*: https://www.thewindowsclub.com/map-an-ftp-drive-windows or - via third party tool - *like*: https://www.ferrobackup.com/map-ftp-as-disk.html Still only a part of the data (those provided by the FTP) are available, so, even if you have *some* access via drive letter, you do not have the same amount of data/access as if it was a local disk drive. In the case of a FTP (please read as "remote") device this is of course "normal", but in the case of PTP/MTP the mass storage device is "local" allright, connected by a (usually too short to be practical in most real world situations) USB cable, and there is no reason for arbitrarily removing (by using the stupid connection protocol) otherwise technically possible ways to access it, if not the utter stupidity and total lack of respect for the customers that are common between the good MS guys and the good Google guys (and all the sheep, which include the large majority of customers and the actual manufacturers of the phones). What anyone[1] would actually want to be able to do would be: 1) periodically connect his/her device to a PC and 2) run a full dd of the phone "as is" to an image or restore the phone to an exact previous state by dding an image to it OR 3) use Robocopy or similar or backup/restore software AND: 4) perform any "common" maintenance for mass storage devices, like copying files, defragmenting the filesystem, etc. This would be easy, simple and effective, needing not an internet connection (think of the stupid "cloud" backups) nor any particular software from the manufacturer of the phone device (usually crappy, bloated and what not). Probably too simple and easy . jaclaz [1] anyone with some common sense, I mean, a very small minority of people in my eperience.

I've had to use MTP a handful of times with a smartphone and XP and myself found it to be profoundly annoying.. so much simpler to have the media mounted as a drive rather than a device. Not to mention pure USB Mass Storage Mode allows for much greater backward compatibility with OS'es. Just my opinion though.

See also: jaclaz

Just a general side note, regarding those 2 "application data" directories: C:\Documents and Settings\User\Application Data\...profile... C:\Documents and Settings\compname\Local Settings\Application Data\...cachedstuff... Those had confused me mighty for years, before realizing there's actually two appdata folders. And then was initially confused yet more: huh - two?? But it's a good idea to kepp the second folder in mind too. It's a strong suspect if sometimes the browser acts weird, as if it had a ghost cache somewhere... and that's exactly in LocalSettings where it's hiding. For example if an addon gets disabled but stubbornly still has some lingering effects or similar. XUL stuff is cached in the startup-Cache folder, as seen in the screenshot, and it can be deleted to clean up and refresh itself. Basically the profile folder is for user stuff, and the LocalSettings folder is for machine-related cached stuff, just for faster startups.