elfchief

Cool, maybe this means they'll finally be able to afford to implement the ability to play through a non-default sound device on Windows. You know, like the USB DACs a lot of music lovers have.

Also, 150 isn't really that many, resource-wise. A modern computer should be able to handle that trivially. So even if my use case was unreasonable (I obviously don't think it is, obviously), there's no good reason a browser shouldn't still be able to support it well.

In a lot of ways, my open tabs are my to-do list. Some of them are things that I need to do, some are "I want to read this article when I have time", some are long term research.

I've tried doing things like bookmarking things to read later, or saving them to Evernote or Instapaper or whatever, but I never went back and actually read them. Ever.

So, this workflow actually works for me, even if some people would consider it unwieldy. It actually works pretty well, until Chrome starts getting annoyed. I probably average more around 120, but I've got a couple of projects happening simultaneously right now, so I'm up around 150 at the moment.

Wow. I've been getting more and more frustrated with how poorly Chrome handles even a moderately large number of tabs (~150), and it sounds like my savior is going to be ... Firefox. Huh.

Wouldn't have guessed it, but I'll totally take it.

I have a nice extension for Chrome called Quick Tabs that gives me a searchable list of my open tabs and makes it easy to find things I have open... anyone know which of the several things that seem to do that with Firefox would be the best to use?

Anyone know what software they use to do the Vimeo video in that article? I've been wondering for a while, when I've seen videos like that...

Well, sure, you can make that assertion, but when you have someone that is a) already pretty familiar with the technology, b) continuously keeping track of the product for years, and c) goes out of their way to try to educate themselves... and that person still feels kind of lost... sure, you could put all the blame on them, but that seems a bit disingenuous.

(Or you could make the assertion that I'm just an idiot, but my career suggests otherwise.)

> Do you know that keeping your users in a constant state of confusion is not the way to > convince them that you're building a stable and secure product

This.

I was a very early proponent of docker, and have been using it continuously since the very early versions. I read the release notes and most weeks I read the weekly email newsletter, and I still don't really have a clue where Docker is going, what its current status is (as far as how the various pieces fit together, etc) or what half the new features even do.

The docker team's communication is really poor, and their documentation seems even worse, unless I'm missing some oracle somewhere that fills in all the details that the actual documentation leaves out...

Also their refusal to allow a feature to let a company change the default registry. Many enterprises need their own registry (and really want it to be the default) for a multitude of reasons... but they always just go "but we want everyone to have the same experience so we won't add this feature", even though there's been patches offered.

Actually, by the speed of sound. When you move an object, the pressure wave that travels along it and makes it move with you propagates at the speed of sound in that material. Still pretty fast at human scales, though!

> Do these people just rubber stamp a bill because there's a D or an R next to it?

Pretty much, yes. It's fucking depressing.

The problem with multiple geographic locations, in this context, is that you'd have to read from all of them, and compare the results, to know that you have file corruption. Which is, needless to say, not something that it makes sense to do.

The purpose of data block checksumming isn't to make your data more resilient (at least directly), it's to make sure you know you have a problem. Once you know you have a problem, then you can go read from your alternate datacenter or whatever.

If nothing else, you can log the error. If you have RAID1 you can recopy the block from a good copy. It is, honestly, probably situation-specific, but step #1 is always going to be "identify that you have a problem"

It really bugs me (and has for a while) that there is still no mainstream linux filesystem that supports data block checksumming. Silent corruption is not exactly new, and the odds of running into it have grown significantly as drives have gotten bigger. It's a bit maddening that nobody seems to care (or maybe I'm just looking in the wrong places)

(...sure, you could call zfs or btrfs "mainstream", I suppose, but when I say "mainstream" I mean something along the lines of "officially supported by RedHat". zfs isn't, and RH considers btrfs to still be "experimental".)

Really cool idea (though .. no Apollo 13?), but MY GOD does the typography on the webpage suck. I couldn't even read the whole page. I hope the app has better-considered design!

If you're going to say that, you really should build your packages appropriately. e.g, right now, you have:

$ repoquery -q --provides docker-engine-17.03.0.ce-1.el7.centos docker-engine = 17.03.0.ce-1.el7.centos docker-engine(x86-64) = 17.03.0.ce-1.el7.centos

...compare to, say, python (I've elided a few things for clarity):

$ rpm -q --provides python python = 2.7.5-48.el7 python(abi) = 2.7

If you do something like: Provides: docker(api) = 1.23

... this at least means that folks can depend on/install 'docker(api) > 1.23' or whatever if they actually want to get a specific semantic version.

I'm still shocked that the spotify desktop app won't let you output to anything other than the default audio device. There's an open request with thousands of votes on their tracker that has been in "not right now" state for half a decade. I know people with multiple outputs aren't a majority, but c'mon, it's gotta be less work to add than pretty much every other "feature" they've added in that time...

If only there was some way a frontend system could queue things until a backend system was ready to accept them...

Websites that don't work on weekends (of which I've seen more than a few) are really quite possibly the stupidest thing I've ever seen. I shudder to think that somewhere there was a requirements document that details what days the site should and shouldn't work...

In the vast majority of cases, a relationship that is broken with two participants is going to be broken with more than two participants. People don't suddenly become less obnoxious, more mature, less possessive, just because there's someone else around. If anything, existing problems tend to get rather amplified with the addition of more people.

The main case where this isn't true as much is when a relationship is otherwise good, but there are specific things that are missing -- there's not conflict, just things missing. For example, if one person in a couple enjoys BDSM and the other doesn't, adding someone that can fulfill that desire can be quite helpful.

There's always exceptions, of course, but that seems to be the way things generally work out.

HIBP is still useful to me, at least, because it will let me find breaches for my entire domain, rather than just for specific email addresses. This is useful since I use a different email address per-site (username-somestring@domain), so just being able to search on my base email address on HEROIC isn't likely to turn much up...

There is certainly hardware available that can do better than this, but the parent asked about cell sites in specific (and cell sites are one of the top users of the Thunderbolt). You can get GPS hardware based on atomic references, for example, that will do better over these kinds of timespans.

(You really need GPS or some other precision time transfer mechanism for long-term accuracy, though ... there's no getting past that.)

Anywhere that GPS is used in a timing-critical application, they'll be using a timing receiver (like http://www.trimble.com/timing/thunderbolt-e.aspx) to handle their time reference; those use the GPS signal (when they have it) to discipline a (ovenized) quartz crystal, so that they have good performance during "holdover" (loss of GPS) especially for short-term outages. In its default configuration, the Thunderbolt-E linked above, for example, will be within +- 8us after being in holdover for 24 hours.

I found an error on the linked page, but unfortunately the author doesn't appear to have contact information anywhere, so I can't really report it. :(

That page (in 'The Details') reports that the length of a year will change over time due to leap seconds, but that's not actually the case -- leap seconds correct for changes in the Earth's rotation on its axis, but years measure the Earth's trip around the sun, and these two things are unrelated.

(Leaving here on the extremely off chance the author of that page reads HN!)

By this logic, crypt(3) creates encrypted (rather than hashed) passwords, because it can be implemented with DES.

It's not so much that the military signal (ranging code) is encrypted, per se, but it uses a DRNG for which the parameters are kept secret.

To be able to spoof GPS, you need to be able to duplicate the ranging code for a given satellite. This is easy for civilian GPS, where the code repeats ~1000 times/sec and the details are public; much harder for military code where it repeats 1 time/week and the parameters are secret.

You can still jam either one, though, just by overwhelming appropriate frequencies with noise. This is what the spot beam in newer satellites is for -- getting more power to areas of conflict to make the signal harder to jam.

This reminds me of what I went through back in ~2004 with a VW wiring harness.

I had a product (a little toy that would give better control over the automatically-deploying spoiler behavior on turbocharged New Beetles) that was built around one specific VW wiring harness.

Apparently not many extras of the harnesses were manufactured, because after we bought ~15 of them (just enough for our first small run), the main distributor for parts in the US ran out of them. We got a few more by having some dealers do nationwide parts searches for us, but we had basically ended up buying out the entire country for this particular harness.

We spent a ton of time trying to figure out how to work around this. We'd really hoped that we would be able to just construct the harnesses ourselves, but the connectors ended up being custom parts that the OEM was unwilling to sell to us. For a while we thought about giving people a discount on the product if they'd send their old harness to us, but we only had a couple left at the time, so that would really end up trashing our throughput. In the end, we just ended up waiting until their was new stock available, almost a year later. It really sucked to have a product that a bunch of people wanted, and not be able to ship it because of a couple of connectors!

Anyhow, yeah ... I feel the author's pain.

Nice presentation! Thanks for the link!

The particular nit you pick here is a fair one, if you take my comment literally, rather than as the (over?)simplification of a complex concept I was trying to summarize.

Yes, in absolute terms, an atomic clock will have excellent stability over the long term in its own frame of reference. As long as you don't need your atomic clock to match any other clock in the universe, the long-term stability is excellent.

The particular topic being discussed here, though, is equipment that is designed to synchronize events across a large area. Even atomic clocks that are literally 100% accurate will diverge if installed in different locations. So if you want your atomic clock to actually be able to tell you what time it is (in a way that matches up closely with anyone else), you have to constantly be adjusting it to match a common standard (e.g. UTC)

These adjustments are a form of instability, since to correct for changes, you have to make your seconds either faster or slower than they actually are locally, on a constantly-changing basis, or you have to step your time and have less (or more) than (Y - X) time actually elapse between timestamps X and Y.

As soon as you move beyond a single frame of reference, you can't have both short and long term stability.

I suppose I could have used a different word than 'stability', but that seemed to get across the underlying effect best. I suppose another way of saying it (that is more correct) is that atomic clocks are great for telling you how much time has passed (in your local reference frame), but not so great for telling you what time it is. GPS is great for telling you what time it is, but not so great for telling you how much time has passed (in your local reference frame).

(The best clocks for timekeeping, of course, are atomic clocks disciplined by a common reference like GPS, which gives you the option of deciding your own long term vs. short term tradeoff however you'd like. But the original question was "why do we need GPS at all, and not just atomic clocks?".)

Even Google's "now" is still a little fuzzy -- their system doesn't so much define "now" as it defines the uncertainty around "now", which you can take advantage of for figuring out ordering. This paragraph (from section 1 of their paper) summarizes it pretty well:

> The key enabler of these properties is a new TrueTime > API and its implementation. The API directly exposes > clock uncertainty, and the guarantees on Spanner’s timestamps > depend on the bounds that the implementation provides. > If the uncertainty is large, Spanner slows down to > wait out that uncertainty.

...so really, GPS and atomic clocks aren't for defining "now" they're for providing a keeping the window of uncertainty around "now" to a small value. The value mentioned in the paper for this is "generally less than 10ms", which is pretty good for a large-scale distributed system, but massive in terms of precision timekeeping. It is, after all, an uncertainty that's three orders of magnitude larger than the GPS glitch that started this discussion...

It's not that surprising that it has a problem with error, because the reality is, there's no correct solution for dealing with this kind of error.

The first question, of course, is "how do you determine when there's an error?" Half the GPS constellation was broadcasting the data, and for almost all purposes it was 'correct' data, other than being wrong. Perhaps ground stations could determine that they're getting different data from different satellites (if they have some good ones in view), or maybe they could just decide that the new parameters differed enough from the old ones to be implausible, but neither of these is a cut and dry "I definitely have an error" ... but let's say you have a foolproof way to determine that A0/A1 are incorrect. Great. THEN what do you do?

You could just decide to use the previous value for that parameter... which is great for a single clock, but what about clocks elsewhere that have a different value (the one being broadcast by the rest of the satellites) or an out of date value (say, a clock that was powered off while traveling in a broadcast van)? Barring external communication, you could have an arbitrary number of different interpretations of the current time -- a different one for each ground station!

You could also just accept that the new parameters are correct, but how do you then get your clock to the new correct time, without having a second (or other time period) that's significantly longer or shorter than a second? There's a lot of gear that expects a second to be a specific length, which is not gonna be happy if the length changes. (Think of playing back an audio file that's exactly 30 minutes long, and needs to start and stop at specific times, down to the bit. You then configure your system to send one bit every (1/bitrate) seconds exactly. How does that system recover when 13µs of bits go missing? How do you coordinate that behavior over multiple disconnected systems around the world which may have gotten the same information at different times (or not at all)?

From reading the article, it sounds like what happened was that the units didn't fail because of the GPS issue, but that they start throwing alarms (probably while going into a mode where they ran off only their internal (disciplined) oscillator. This seems like absolutely the right thing to do -- "uh, boss, things look really not-right here, and I can't fix it without breaking something, you really need to come deal with this yourself." (Note the comments about 'thousands of system warnings' but none about 'cellphones broke.') This is, from what I can see, really the only reasonable behavior these devices could have.

(disclaimer: I don't have any direct data on what broke vs. what complained loudly and woke people up. I'd love to have some solid, not-parsed-by-the-tech-media data on this topic, if anyone has any.)

The problem with atomic clocks in general is that they have very good short term stability, but not-so-great long-term stability. So they are very good at measuring the amount of time that has passed between two events, but not as great for telling you exactly what time an event happened.

The other problem is that there's not really such thing as a single, true time. Precision timekeeping is one of those places where relativity matters -- differences in altitude and the geology of the earth under your feet at a particular point change how fast any particular clock 'ticks'.

So to accommodate these differences, if you want events to be synchronized across multiple locations over a long period, you both need a single agreed-upon "current time", and some way to get information about that time information to the sites that need it.

You could surely do this with directly connected wires that were very carefully measured, but that gets expensive very quickly. The GPS system already requires super-precise time just to function, so it makes for a great distribution mechanism of "what time is it" information, where the people running the GPS system are bothered with all the details of figuring out and standardizing a single time, and you 'just' have to listen.

The GPS folks also keep track of things like how fast the GPS standard clock is drifting from the UTC standard clock (since no two clocks will agree over the long term, period). And this is actually where the problem happened -- Two of the parameters broadcast (A0 and A1) were incorrect, and it's these parameters that are used to specify the current time difference between the GPS master clock and the UTC master clock (the GPS master clock is disciplined to be as close to UTC as possible, but is always off by a minute amount, and that's what A0/A1 represent).

Pretty much it boils down to, much as it is in distributed systems, "there is no now". Even with maximum care and the highest quality clocks, there's really not a definition of 'now' that's consistent across more than a single location. GPS is currently the closest thing we have to a globally-distributed definition of 'now'.