As long as you understand where he's coming from, and that he's been paid as a lawyer to advocate in the past for clients, his stuff is worth reading. His arguments may be biased towards a specific perspective, but they are well-reasoned and documented in support of his position. That's a lot better than the normal bovine effluent you read from tech reporters or (other...) paid shills.

Even PJ would pick-and-choose references to support a position, that's what "making an argument" is all about.

That being said, Mueller's recent writings on Apple abandoned a lot of the balance they had in years past. I don't know if he lost patience with Apple's positions on the Samsung trials, or if his change was motivated by something less transparent.

http://www.fosspatents.com/201...

Make sure you read his biography to get a sense of where he's coming from in this debate.

Well, that would be less of a problem if you didn't surf SlashDot using your refrigerator or crop-monitoring drone...

I have a couple problems with the implication that "short time to find/fix" is so acceptable.

1. Some amount of damage was done (and no one really knows for sure) through this bug. A fix was identified rapidly after the bug was -discovered-, but that's a long time after the bug was -introduced-.

2. For some systems, particularly those like SCADA systems where we really have deep information assurance concerns, patching software is not easy! Not everything can use "grab the patched source, rebuild and reinstall" or even "download the patch and install" repairs.

Thus the emphasis Has To Be on preventing these kinds of problems, then defending against them. Fixing them after the system is deployed is by far the weakest strategy. (Thus I salute with a full hand the initiative announced today, and discussed on a related SlashDot thread: http://news.slashdot.org/story... )

"We will hear and they will be punished!!!"

http://www.crosstalkonline.org...

And here's my $.02: C syntax has been actively harmful in this regard. It's too easy to make a typo that compiles, or to introduce a statement/expression that has a different result than you expect (e.g. the Apple "extra break statement" bug.)

Fair enough, and that begs the question whether the passengers on the ship could ever tell the difference...

The new captain has set a new course, one that veers away from the rocks. But this ship will take a long time and a lot of leeway to make that turn.

(Of course, I thought the old captain should have been 'relieved for cause' years ago, but since personally I'm neither a customer/user nor a direct shareholder in MSFT, it really wasn't my business :-)

My school had a one afternoon per week gifted students program. Among other things we did programmed/self paced instruction and classroom work on boolean algebra and basic number theory. This was in the late 1960s in a middle class school district in suburban Pittsburgh (Avonworth.)

The other thing worth noting is how most mathematicians make their breakthrough discoveries before age 30. (Sorry don't have the reference for this, but I've seen it widely discussed.) So that means the earlier we expose kids "with the math gene" to more complex topics, the greater the possibility that stuff will 'stick'.

From http://appleinsider.com/articl...
"The most glaring inconsistency is a disconnect between Gartner's 70.4 million iPad sales and Apple's self-reported 74 million unit sales for 2013. From the first quarter — Apple's second fiscal quarter — to the fourth, the company reported iPad sales of 19.5 million, 14.6 million, 14.1 million and 26 million, respectively. The total: 74.2 million iPads sold during 2013. "

Note these numbers are reported by Apple on SEC filings, not on press releases.

If I'm configuring a laptop that I'll use for both work and vacation:

Default Folder (an add-on/replacement for the Open File dialog)
Graphic Converter (photo manipulation application)
Aquamacs (very well done MacOS version of EMACS)
HDRtist Pro (HDR processing application)
OmniGraffle (Mac equivalent to Visio, drawing package)
Aperture (Photo organizing)
1Password (Password safe)
DiskWarrior (File system maintenance)
Syncovery (front end to rsync)

This doesn't include the stuff I find essential that's built into Mac OS X (and its Unix foundations, such as ssh and bash.)

And for what it's worth, I've been using Graphic Converter and Default Folder for at least 20 years, back to Mac OS 7 days. It says something about the quality/utility of these two applications that they've "stood the test of time."

One of the best novels about a realistic and mostly dysfunctional future set in 2010. http://en.wikipedia.org/wiki/S...

and say anyone that doesn't understand EBNF probably doesn't need to be granted SuperUser privilege. If there are specific actions that should be permitted for trusted but unsophisticated users, set up scripts to do only those actions.

And I'll demonstrate my age by saying that Unix derivatives, including Linux, BSD, etc, etc, -have a long way to go- to match VMS for a truly useful/administrator-friendly privilege model.

True, but if your company's product is, for example, software - and that software company is being run by someone with a legal, financial, hardware, operations, or non-software engineering background, the problem is much more difficult. And that's what I'm seeing. First the engineers need to be able to think in terms of business objectives (one of the best courses I ever had was a grad course in "engineering economics"). But second, the management community (starting with the business schools) need to figure out how to train CxOs that actually -understand the business they're in-.

For the last 30+ years, I've been in the large scale systems business. Most, but not all of that has been on projects for the US DoD. I've been appalled by the number of senior executives, military/government, large industry, small industry, who fundamentally don't understand software-intensive systems. As my earlier post said, their software experience is encapsulated in some small-scale programming task, rather than in large scale software engineering. On the one hand, they expect software to perform miracles because "it's software, you can change it," while on the other hand they refuse to invest in software. For the former, the best quote is from a former co-worker, "The software engineer is the system engineer of last resort."

I'm reminded of a system I once reviewed where they had a 'software problem'. But it turned out they had a -networking problem-. They were trying to move large volumes of images over a 10BaseT ethernet connection, and wondered why they weren't getting system throughput. Their ethernet was usually well over 50% loaded and couldn't handle the data. But they expected the software to 'fix' this.