It's a great idea to wear loafers and stop periodically to tie your shoes; people will go out of their way to avoid your personal space. No one wants to collide with a crazy person.
There are plenty of examples of both usages of slower, showing that it is ambiguous across popular usage. For example, there's a whole 800% slower "genre" on Youtube where songs are played at 1/8 of their original speed. When popular usage is so sloppy, it's better to avoid the phrasing altogether in favor of something precise instead.
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.
In your interview process, ask obscure low-level architecture questions, like "What is a trap?" or "What does the BEQ/JEQ/JE opcode do?" These questions will rule out anybody who hasn't ever worked with any form of assembly language.
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.
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".
Even a hardware failure can be automatically migrated away from before it takes down the server and fixed without any down time.
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.
If this were literally a matter of life and death then the national guard should be herding people onto trucks to get them out of danger, and shooting looters in the street.
No, that only happens when people are protesting now.
My description of that map slice was bad. I meant to highlight the EU members that are packed together tightly, which the map did, because those so often are used as the examples I don't think are useful comparison points. My text did not match the map though.
The FCC is the Federal Communications Commission. They can't set rules for the entire country if they are unreasonable for some of the states to follow. That's why I was highlighting that the capabilities of the worst states end up being a limiter for whatever rules they can put in place. They can't say "broadband means X in most states, but because telcos in Alaska can't deliver that they can ignore this rule". That's also loads of evidence that if left alone, telcos will just offer good service in the dense areas, and forget about the rural ones altogether. That's exactly what's happened here with mobile phone coverage, several fiber projects, and before that things like DSL Interent connections. So instead everyone gangs up on them and tries to negotiate for everyone at once.
In theory individual states could raise the requirements above those set at the federal level. Unfortunately, the monopoly problems just get worse there. When there's only one provider actually giving service to an area, states have to legitimately worry about them just pulling out of the state altogether if they're pressed too hard. They can't walk away from a federal negotiation like that.
Slashdot Mirror
Wow, there's an unexpected back-door entry at every step of that plan.
Whoa, thanks for the flashback. I remember reading about your work in some of Abrash's columns.
how about writing music that can be played on a rested grass lawn with minimal overhead and a four-piece band?
Well, some musicians don't like playing to a crowd fully of hippies.
Upsample to 24/96 while you're at it and you can compete against Neil Young!
It's a great idea to wear loafers and stop periodically to tie your shoes; people will go out of their way to avoid your personal space. No one wants to collide with a crazy person.
Do not spend your time synthesizing literature studies.
There are plenty of examples of both usages of slower, showing that it is ambiguous across popular usage. For example, there's a whole 800% slower "genre" on Youtube where songs are played at 1/8 of their original speed. When popular usage is so sloppy, it's better to avoid the phrasing altogether in favor of something precise instead.
No, that dude has been on Slashdot for longer than any 12 year old has been alive. You can tell from both his uid and the terrible car analogy.
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.
In your interview process, ask obscure low-level architecture questions, like "What is a trap?" or "What does the BEQ/JEQ/JE opcode do?" These questions will rule out anybody who hasn't ever worked with any form of assembly language.
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".
Even a hardware failure can be automatically migrated away from before it takes down the server and fixed without any down time.
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.
If this were literally a matter of life and death then the national guard should be herding people onto trucks to get them out of danger, and shooting looters in the street.
No, that only happens when people are protesting now.
Are you sure about that?
You haven't lived until you've poured a PBR into some Fruity Pebbles.
My description of that map slice was bad. I meant to highlight the EU members that are packed together tightly, which the map did, because those so often are used as the examples I don't think are useful comparison points. My text did not match the map though.
The FCC is the Federal Communications Commission. They can't set rules for the entire country if they are unreasonable for some of the states to follow. That's why I was highlighting that the capabilities of the worst states end up being a limiter for whatever rules they can put in place. They can't say "broadband means X in most states, but because telcos in Alaska can't deliver that they can ignore this rule". That's also loads of evidence that if left alone, telcos will just offer good service in the dense areas, and forget about the rural ones altogether. That's exactly what's happened here with mobile phone coverage, several fiber projects, and before that things like DSL Interent connections. So instead everyone gangs up on them and tries to negotiate for everyone at once.
In theory individual states could raise the requirements above those set at the federal level. Unfortunately, the monopoly problems just get worse there. When there's only one provider actually giving service to an area, states have to legitimately worry about them just pulling out of the state altogether if they're pressed too hard. They can't walk away from a federal negotiation like that.