Earlier quoted context omitted.
As someone who recently had Android 6.0 available for their phone and decided to upgrade, exactly this Some genius at Google decided to make the phone vibrate and beep every time there is an open WiFi spot, or you need to sign up to a known one Really This kind of crap (not the only one) almost justifies the extra price for iOS
I (Moto X 2014) got a different set of bugs on M. Mostly problems with basic functionality: - When I get called, half of the time I don't see the name of the person when they are in my address book. - Music controls (which were already very basic) usually stopped working a certain amount of time after the last restart. - Music randomly pauses when browsing the web at the same time (as in, I have to open up the music…
Outlook 2016’s New POP3 Bug Deletes Your Emails
41–50 of 79 posts
Re: Outlook 2016’s New POP3 Bug Deletes Your Emails
#42> UPDATE 02/26/2016: ... TL;DR: Disable automatic updates... That's just good advice for dealing with modern software, for which fixes, breakage, and feature churn are all mixed in a single awful stream. "Newer" does not mean "better."
I use near weekly updates of a custom Android 6.0 ROM and daily use Arch Linux which is a rolling release. My work is on the web with npm keeping us bleeding edge. Other people often ask why my system does this little extra thing that's useful. Usually the answer is found by --version. Life with up to date tools can be real good. So unless I'm simply the only one using good tools, updates can be good.
My primary OS is also Arch Linux, and while it's certainly stable, it's not without its warts. Failure to update regularly on a rolling release distro can have absolutely disastrous consequences (though you only have yourself to blame), and a healthy dose of caution is strongly recommended whenever a major update to important software is in the pipeline (think KDE4 to KDE5 transition). I think this sort of bug (Outlook) illustrates the importance of having an abundance of caution with new software where the failure modes may not be well understood by merit of its relative youth. But with rapid releases, I think the problem is a bit more focused on the end user: Someone who is unable or unwilling to take the risk of updates causing material harm to their workflow or consuming time they can't afford in order to fix potential problems should look for more conservative release cycles. I don't think it's really a matter of "good" versus "bad" tools; that may be part of it, but I can't help myself from thinking it's a matter of misplaced expectations.
That is, it's easy to fall into the mindset of erroneously believing that faster, more rapid updates is always better without fully appreciating their impact. (I've done this more times than I'm willing to admit.)
I do think, and maybe I'm wrong (which I usually am), that those of us who tend toward using rolling release distros have a bit of a bias and a rose tint to our glasses. We almost innately know what the risks are, and I think we take that for granted by assuming most others will freely accept such risks and appreciate the occupational hazards that go hand in hand with change. Not everyone has the same degree of patience, nor the same goals or motives. I think our optimism for and evangelizing of software that pushes rapid releases (like Arch, as an example) can help create an aura that lulls those we influence into expectations that don't mesh well with their use case, their personality, or their constraints. Is that a bad thing? I don't think so (evangelizing is important), because I do agree with you: Updates can be good. I just think we're all too happy to espouse advantages while sometimes glossing over potential drawbacks (guilty again as charged!). :)
Anyway, I should apologize: I didn't mean to wax philosophical. It's late in my timezone, and I saw another Arch user who provoked me into a short essay. I agree with you and username223, but I don't have any real answer. I do think that sometimes we ought to be more cautious with our advice and perhaps weigh context more heavily than our excitement allows. (I made the mistake once of suggesting Arch to someone who really ought to use something with sturdier training wheels. My only saving grace is that he never got around to installing it.)
Re: Outlook 2016’s New POP3 Bug Deletes Your Emails
#43Earlier quoted context omitted.
I almost totally agree. If it wasn't for security fixes, there would be no value in updating almost any software. If it's already working OK, just leave it alone. 15 years ago when people had problems with their graphics cards, the standard "fix" was to update the driver. Now we're still updating drivers. Weren't the problems supposed to have been fixed many years ago? It seems they introduce as many new bugs as they…
"Now we're still updating drivers. Weren't the problems supposed to have been fixed many years ago?" Your statement makes sense if you believe that graphics card manufacturers were still working on drivers for 15 year old cards and 15 year old APIs. Manufacturers are always putting out new cards, and there are new APIs to support. Writing drives for dozens of chips spanning multiple generations of graphics architectu…
Re: Outlook 2016’s New POP3 Bug Deletes Your Emails
#44> UPDATE 02/26/2016: ... TL;DR: Disable automatic updates... That's just good advice for dealing with modern software, for which fixes, breakage, and feature churn are all mixed in a single awful stream. "Newer" does not mean "better."
Re: Outlook 2016’s New POP3 Bug Deletes Your Emails
#45Earlier quoted context omitted.
I've used git on several hosts and subversion back in the day. I have no problem learning new things. Tortoise, bitbucket, github, beanstalk to name a few. I think your reaction is more horrifying than me not having a compelling reason to change the way I've been doing things without flaw for decades.
So long as it works for you, thats great - I just hope you have a migration path if/when it stops working. I do however get the objection to newer is better, I keep getting besieged to move my projects from svn to git - to which I usually respond "Why, tell me what feature we need in git, that svn doesn't do?" I've yet to get an answer.
Re: Outlook 2016’s New POP3 Bug Deletes Your Emails
#46Re: Outlook 2016’s New POP3 Bug Deletes Your Emails
#47Earlier quoted context omitted.
Look what Microsoft did with *.odt (OpenOffice/LibreOffice) compatibility. Now they show bogus security and compatibility warning dialogs if you open or save such a file. Look what they do with IMAP support in Outlook 2016. Pre-loading just the "Subject" (a feature supported since 1990s) got dropped, instead of the whole email incl attachments is downloaded. And now we learn POP3 got crippled too. The common Microsof…
The funny thing about Microsoft is they use people's belief in Hanlon's razor as a competitive advantage.
Re: Outlook 2016’s New POP3 Bug Deletes Your Emails
#48Re: Outlook 2016’s New POP3 Bug Deletes Your Emails
#49> UPDATE 02/26/2016: ... TL;DR: Disable automatic updates... That's just good advice for dealing with modern software, for which fixes, breakage, and feature churn are all mixed in a single awful stream. "Newer" does not mean "better."
I'm genuinely surprised Microsoft allows disabling of those automatic updates...
Re: Outlook 2016’s New POP3 Bug Deletes Your Emails
#50Earlier quoted context omitted.
I've used git on several hosts and subversion back in the day. I have no problem learning new things. Tortoise, bitbucket, github, beanstalk to name a few. I think your reaction is more horrifying than me not having a compelling reason to change the way I've been doing things without flaw for decades.
So long as it works for you, thats great - I just hope you have a migration path if/when it stops working. I do however get the objection to newer is better, I keep getting besieged to move my projects from svn to git - to which I usually respond "Why, tell me what feature we need in git, that svn doesn't do?" I've yet to get an answer.
- Familiarity. Everyone uses git nowadays; like it or not, svn projects are the odd ones out.
- Fast, offline querying of the project's history. With git, they have a full copy of the project's history in their local computer, while with svn, any query has to go to the server. This helps a lot when chasing regressions, or just when browsing the changes between one release and the other.
- Easy branching. Branches in git are more lightweight than branches in svn, and git's merge functionality is quite good. When they want to propose some change to your code, they can just create a branch in their local copy, make the changes they want, publish the branch somewhere, and ask you to merge it; this is made even easier by sites like github. With svn, unless they have an account in your svn server, they have to do it the old-fashioned way.