I don't know who this CNBC are, I'd be looking to Netcraft to confirm whether Intel are dying.

Parsing that summary, was it all-digital 50+ years ago?

It's not about programming: engineering reliable computer systems is about how you work with the organisation and people around you to deliver, to prove you've delivered, and to keep alive your system.

If you don't understand your code well enough to teach it to anyone -- especially those less technical, educated or experienced than you -- you don't pass review.

If you don't practise for critical incidents -- which firefighters and emergency-response teams do -- you'll make that unexpected bad day a whole lot. Be ready, spend time to be calm, prepared and (above all) practised.

If you're fire-fighting -- and people love to praise a hero -- then get yourselves enough time to reflect and learn from what's going on. Trust your colleagues, because almost nobody shows up to intending do a bad job, to find out and prevent re-occurring mistakes.

It's great that your planning, design, implementation, testing, deployment and monitoring can react in an agile way to changes in your business needs, but doing that with sporadic and ad-hoc meetings is extra strain on your team. Make the meetings routine and clockwork so that it can be low-exertion in contrast to the creative work of documenting the failure modes (in test cases) or designing the interaction, moving parts of the system.

Learn from history:

• The team that brought us everything-is-a-file paradigm of Unix got together later to think of the next iteration for networked computers. The pattern of small services responding to inter-process communication passed through message buses, so your containerised services can be daisy-chained together to provide your software-as-a-service, is an echo of the microkernel of Bell Labs' Plan 9 From Outer Space with its paradigm of every-app-is-a-server.
• Mainframes had time-sharing and many programs running for a wide range of users back when there was 'maybe a market for six computers worldwide' (IBM's Thomas Watson), which enterprise virtualisation and cloud service providers are reprising today.
• 'Your shipping software is your org chart' is a paraphrase of a 1967 piece of wisdom my Melvin Conway; Conway's law reads: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."
• Amdahl's Law for the limits of parallelism and how organising work to get speed ups from the embarrassingly-parallel bits has echoes in team structures where organising the work can dominate time spent in place of completing the tasks ahead of you.

Short for "We Don't hire over 40's."

Get off my lawn, kid.

No real comparable thing exists, and to expect it is to think in the MS single-microcomputer-on-every-desk mindset. We're networked and clouded these days, so every program is a server which can interact with any other program (or should be) and a single-lump tool is limited to its black box. In the Free/Open Source world, you can get full SQL DB's or NoSQL storage engines free-at-point-of-use, so why would you grab a single solution when you can pick the components which best fit your needs?

I think you've condemned your many clients to no scalability and little flexibility. When it comes to cope with larger numbers of records, more complicated business logic or increased concurrent access, there's nothing like Access in the Free/Open Source world because the big-boy DB's are free-at-point-of-use. You then have the freedom to implement a web UI or a GTK+ UI or a QT UI talking a standard protocol and standard DB query language, and with that comes the architectural freedom to divorce the back-end from the business logic from the user interface -- which makes maintenance and ongoing improvements easy.

Can you name and shame your customer*, so I don't get delayed by parts from that DB when it goes pear-shaped? Data should be transferrable; migration -- like backups and disaster recovery -- should be a thing we expect as normal for digital information.

*: well, no you won't, this request is hyperbole on Slashdot.

http://www.schneier.com/blog/archives/2013/03/our_internet_su.html

But... if I were going to try and confound the system which can correlate almost all of your electronic records, you'd need to have a rolling list of sock-puppets who supply proxy identifying information to the cell towers. You'd need to have a bundle of SIM cards in the handset to do this, or to have electronics which fake the same data. Then, to make sure you can actually be contacted, you need to have a call redirection system sending you SIP calls (though if you're designing the hardware for this, you can encrypt the data streams carrying your voice over the existing cell transports - note that Skype may be encrypted but we don't know how well or who has a back door key). To avoid that being a single point of obfuscation failure, it probably needs to be a distributed network of TOR-like relays across hardware and cloud providers, and even then, it will probably need to be steganographically hidden in ordinary-looking traffic.

Not impossible, but still a pipe-dream since 1993.

Rob Pike's setup on a Macbook Air with Plan 9 From Userspace is nearly there. See rob.pike.usesthis.com/, and there's no way that a full 9p system shouldn't be usable on a phone or tablet.

How extensive is the undiagnosed population, and how fast is that population growing, and how much will they cost to treat?

You have a 1 in 100,000 of a 20+year ailment giving you symptoms which cause its diagnosis and treatment. Most carriers are asymptomatic, and the article states that no-one knows how many people are carriers or how many more infections they cause.

I'll suggest that the undiagnosed population is a few million, but it's not growing fast because most people wash their hands after pooping and before preparing food. Your fiscal choice is to wait until it becomes a problem (cost:billions, using your number above) or to pay for preventative work which studies the problem and works to diagnose and lower the asymptomatic-yet-parasitised population (cost:millions). Your call.

I took is as grand satire, merciless in ridiculing its targets, and I laughed most of the way through it.

May I add my contribution to the many elucidatory and finely-expressed commentary as is usual here at Slashdot?

I've not seen anyone ask which Linux platform Steam is going to arrive on. There's desktop Linux, which may make a fine foundation for a 'Punk' or 'Boiler' Steam box*, or there's Android, which will help Steam sell to casual, mobile and hand-held users. Steam games on either would be quite welcome.

*: Steam Punk variety has ornamental gears and intricate woodwork (I'm sure you could see that one coming).

"Being intellectually sound, however, is not sufficient to affect change"

Can we have the argument about affect and effect here? I would have used 'effect change' here, unless OP means that change, in some way, is to be altered.

Also, there an enormous issue about how invested we all are in the existing system, with jobs and housing provided by it. That makes it very costly to change - but it's quite costly to stay paying a mortgage which supports the lifestyles of the people who sold created and sold CDOs and which is also rescuing the present situation.

I'm a software tester in an organisation which has clear delineation between manual testers, software test engineers who build automated tests and developers (I gotta say that I speak for me and not them here - that's the policy out of the way). The first two of that list need to have a 'question everything' testers' mentality; the last two need to have a technical grasp of how the whole thing works, from the core OS, servers and transports to the libraries used and the UI.

A manual tester is concerned with the human experience of your software. Typically there will be a script of the exact actions or the class of actions the manual tester is expected to cover. Some firms roll regression testing and new feature testing into the manual tester's role, others have a separate user-acceptance testing team who stand between released software and deployment.

The automation tester's role is to make the computer test the software, by building a framework around the program and its installed environment to check the system as-a-whole does the intended job. Some automation testers also write unit tests in the core program code; mostly this is left to the developers, who are increasingly being asked to show that their code works - and doesn't break the existing code - before check-in. Some places operate a Behavior-Driven Development (BDD) process where client needs are expressed in testable ways - so that the evidence that your software does what a client wants is written down clearly for the client to see, the tester to test and the developer to build. Some BDD systems even build tests which show that these goals are met, and are known as Test-Driven because the proof of rightness is shown by the tests.

Preparing for an telephone screening or interview about software test engineer, you will need to show that you're technically-minded, that you've worked engineered a test system before, that you understand the benefits and shortcomings of building such a system (such as knowing when to build tests and when to leave low-hanging test fruit to manual testers), and that you're concerned for the quality of the product more than for building a new toy test rig.

I disagree with nearly every point made above, but I know this as a tester: there are a lot of people who shuffle into testing because it's the gateway to working in software. That's no bad thing. But mix it with the lack of confidence to apply for and get developer roles, and you will probably harm your sanity and your career. In every job, you need to be competent and confident. On top of that, you need to be personable so, for example, you don't make bug reports critical of the developers who made them (and know how to calm down a dev who's got that idea).

To be a good tester is genuine hard work requiring the best of your technical insight, pedantry and commitment to high standards, but to be a great tester will call for charisma, kindness, honesty, good working relationships, and the skills to help make a dysfunctional team work right.

If you're only a tester for a short while and move on to a developer role, you can either blame the economy for not having enough dev jobs (so you compromised in order to fulfill your passion for making software), or you can say that you wanted to improve your developer skills by learning what it's like to be on the other side of the fence as a tester. It's not a black mark if working as a tester makes it a benefit to you and a prospective employer.

Content too? I think that you could easily co-opt this by supplying a farm of content-producing people for Y-Combinator to invest in, making them subject to the same market forces -- or putting them in the same boat -- that the movie studios and record companies are.

The fix requires more and better entertainment, more and better news reporting, more better-aware citizens and more and better political engagement. Make reading up on news get you points in some kind of alternate-reality game (ARG), discussing news and being politically active gets you points, too. Perhaps points to make your shopping or recreation cheaper (but there's probably other incentives).

You like your OLED display? That's inkjet-printed. I figure that Cambridge University has tamed the Inkjet -- the OLED was discovered there, too.