I know it's just anecdotal, but FWIW I've been running Arch for five years. In that time, I've had an update-related issue twice: once was a Gnome problem when Gnome made the switch to Wayland, and once was very early on when I was using proprietary graphics drivers that weren't compatible with an updated kernel (I've since switched to the open source drivers and had no more issues). Both of those were easily resolved. I've never needed to reinstall (unless you count a hard-drive failure, but I didn't really reinstall, I just restored from backups after replacing the failed drive). I've never had any broken packages.

I think if you read the Arch News (which will inform you of any manual changes that might be required when updating -- which is extremely rare) and run pacman -Syu once a week or so, you're likely to avoid any serious problems. I know I've been very happy with Arch and the rolling release model (not to mention its excellent documentation). I won't be returning to a non-rolling distro (although I do still have a soft spot for Slackware, so I wouldn't disparage your choice of distro).

Yeah, yeah, of course. But c'mon. To mention "credit cards" and not complete auto financing seems surprising, to me, given the entities that are involved.

It says the leak doesn't include any credit card information. Uh...who buys a car with a credit card? What about loan/bank/financing information? (Not to mention SSN, DOB, address, et cetera.)

A difference in your return doesn't indicate anything about whether you paid more or less tax compared to earlier years. You may have paid less tax and also seen a lower return because your withholding changed.

My return dropped this year, so I'm part of that trend. But I also paid less tax this year.

At one time, Java was my most-used language, dominating the server-side and also being used for Android. These days, my most used languages are ECMAScript/JavaScript on the server (and browser), Swift for iOS, and Kotlin for Android.

I don't think my anecdotal experience is evidence that Java is dead or dying, but it wouldn't surprise me if Java's use is declining, generally. But that's no big deal. Originally, my most used language was C. Then it was C++. Then it was Java. Et cetera. But C isn't dead. C++ isn't dead. Java's usage may decline, but I doubt it will "die" for a long, long, time.

Also, there's the JVM aspect to consider. Languages other than Java target the JVM: Kotlin, Groovy, Scala, Clojure, et cetera. I wouldn't be excited about coding in Java, these days, but I'm happy to code in Kotlin or Clojure.

Mod parent up.

This isn't a "Linux 4.20" problem, this is Intel's fault.

According to posts on aur-general, the known affected packages are:

• acroread 9.5.5-8
• balz 1.20-3
• minergate 8.1-2

According to comments on the AUR acroread package, the script the compromised package installed (to upload system details) contained an error and wouldn't function properly. The script also installed a systemd timer, and the comments advise checking your system for:

• /usr/lib/xeactor
• /usr/lib/systemd/system/xeactor.timer
• /usr/lib/systemd/system/xeactor.service

As a side-comment, for those unfamiliar with Arch, these compromised packages are not part of the official Arch repositories. The AUR is a "user repository": a collection of user-supplied packages which require deliberate download and installation. AUR packages should [i]always[/i] be reviewed before installing them, and not installed if you don't trust the package. As the AUR documentation explains, "Warning: Carefully check all files. Carefully check the PKGBUILD and any .install file for malicious commands. PKGBUILDs are bash scripts containing functions to be executed by makepkg: these functions can contain any valid commands or Bash syntax, so it is totally possible for a PKGBUILD to contain dangerous commands through malice or ignorance on the part of the author. Since makepkg uses fakeroot (and should never be run as root), there is some level of protection but you should never count on it. If in doubt, do not build the package and seek advice on the forums or mailing list."

C++ and JavaScript share a common issue, in that both languages have some design problems that they carry with them, but both are popular and have layers of syntax accumulation and libraries, and both will allow you to write some terrible code.

However, if you have a firm understanding of the languages (and the pitfalls particular to each), you can also write solid and elegant code in either language. It's more a matter of avoiding their bad parts than anything else, but it requires knowledge and discipline to confine yourself to the "good" subset within each language.

No doubt we'll pay for the "new jobs" this creates by taking some money from everyone else's paychecks. Or we could just create some new dollars and spend them before the market adjusts prices to account for the increase in the amount of currency. Kind of a "stealth tax" on your savings account (we don't directly take your dollars, but they buy less than they used to). The possibilities are endless!

Missing option: hot grits.

Linux is my main OS, but I see no compelling reason to run Linux as the native OS on a MacBook. If you want to run Linux on a laptop, get a laptop with better specs and run Linux on it. If you want a MacBook, just run MacOS.

The primary reason I own a Mac is for Xcode and iOS development. I'm hoping Apple updates the Mac Mini soon. If they do that, I'll get a Mac Mini for iOS development and replace my (aging) MacBook Pro with a Linux laptop. (I run Arch on my desktop/workstation, but I might give Ubuntu a try on a new laptop.)

I didn't take JS seriously until after I read Crockford's book. That was illuminating. Even older versions of JS can be okay if you understand the nature of the language and what you should avoid. And I agree it's (mostly) gotten better. Using modern ECMAScript is actually pretty nice.

I was on a team that "used agile" for while. The thing is, our development workflow "before agile" already addressed the main ideas in the agile manifesto, so in practice what happened is that our development workflow was unnecessarily modified (disrupted?) to include more "agile practices" like pair programming and other buzz words (user stories, rigid application of TDD, et cetera). We didn't see much (any?) real benefit. It eventually got abandoned. Can't say I miss it.

I've got no problems with the ideas in the agile manifesto. I'm just not convinced that the practices and culture that often gets included are always worthwhile.