Clueless defense contractors are numerous. But since the core of the US government purchasing is Open Source First, there is little hope of Microsoft regaining any serious hold in that market.

No, it will just make you a trivia-based interviewer. You need to be a serious authority on every aspect of a thing before you can create a comprehensive question like that. These two both have problems. I can tell how old you are from how you asked them.

The i386 processors that are all many people use now call those interrupts, not traps. And there are over 30 branch instructions in that set. JE is one of them, but I wouldn't expect people with only a small amount of assembly language background to remember that particular combination. You can easily write non-trivial 386 programs and never use JE.

This is not that hard: ask "have you ever written anything in assembly language?", and if they say yes, ask how it worked. No opcode trivia is necessary.

Web development now is all about plugging components together as quickly as possible to ship code. Anyone who pauses to try and actually learn how things work is at a disadvantage. While you're doing that, your competitors have already shipped something that worked well enough for people to use it.

Also, there's little sense really digging into things like libraries when they change so quickly. I'm doing this project right now that's all Go based. People who did a deep dive into learning how their previous tools are again regretting that.

Databases are an abstraction level on top of filesystems. You effectively said that you build a filesystem by using a filesystem.

Audrey Tang? Really? Your lead example is someone known primarily for their epic failed project?

See office password protection. The encryption of Excel version before 2007 was laughably weak. The last such file I had to crack took minutes. And that's still what you get if you use the older file formats.

The encryption starting with Office 2007 is as strong as your password. It's still possible to break weak ones, but you need to apply a fair amount of brute force. Here's a typical cracking program. The way it advertises support for multiple cores and GPU acceleration is a clue it's not trivial to crack.

But the question was how to compute the range of addresses it allows. Knowing the subnet mask isn't enough to do that. You also need to know the rules for what numbers you can't use in each subnet block. Not even all the calculators out there get this right. The first hit I got back from searching for one didn't; here's one that does. For the example here, "Usable IPs = 192.168.0.1 to 192.168.0.254".

The history of automatic fail-over software says that when you add some, in addition to the old issues you now have bugs in the fail-over software as a new problem.

I work on nothing but open-source based PostgreSQL servers for living, effecively competing against EnterpriseDB. All of the Oracle migrations I've done convert their PL/SQL code to PostgreSQL's PL/pgSQL instead. There's always some amount of application and process refactoring when you're moving to another database; this gets wrapped into that. I do a few training classes each year on the quirks of PL/pgSQL, and most companies don't do anything so complicated in there that they can't move things over.

It's often not even the biggest single migration hurdle, and despite their marketing claims EnterpriseDB doesn't help at all with the rest of them. The ugliest single conversion I've been involved in was an app where some developer loved CONNECT BY statements. My company at the time had to write a whole QA suite to make sure the replacements for those queries gave the same results in Postgres as the Oracle version.

DACs that re-clocked were popular in the late 90's. Then the falling prices of computer hardware eventually made buffering inexpensive enough to use instead. The original interface for CD transports to DACs came out in 1983. Parts of that design were based on what was economically feasible in consumer electronics then.

A lot of high-end audio gear aims toward a simpler is better design ideal, which is what excludes switching power supplies. My main concerns are with longevity. I have amplifiers here going back to the 60's that are still functional and serviceable. I haven't seen any switching power supplies that I think I'll be able to repair usefully decades from now.

There are two things called jitter here. When you're ripping a CD, sometimes audio reads will not give you the same block on the disc each time you ask for it. Older ripping programs had to read multiple times to correct that. Newer drives support "Accurate Stream", which makes this sort of jitter go away altogether.

CD transports do not have this problem. CD read jitter only happens if you're trying to read audio CDs at the block level, something they weren't really designed to do. A regular CD player will not do this.

The second type is transport clock jitter. The digital interface between CD transports and DACs doesn't have a separate clock. It's derived from the data itself. That process wasn't always perfect. In the mid 90's, the recovered clock was sloppy enough that bad ones were audible. Stereophile did a useful article measuring cd transport jitter during that era.

Nowadays the clocks and clock recovery circuits are so much better, I'm skeptical this is a real issue anymore. And most computer audio players buffer their data and then generate their own clock, which completely eliminates transport jitter.

[gsmith@thing1 ~]$ ping thing2

2015 is actually the year of Linux on the hoverboard.

No, that only happens when people are protesting now.

Are you sure about that?