.. which is entirely different to the telemetry system where usage stats are reported. You can see that on data.syncthing.net. But again, thats a separate opt-in. The suggested env variable on the site won't turn that off.

It was really telling at a smaller company that was trying to behave like a big company. I asked a coworker (who had great metrics) what the secret was for dealing with the middle-management-heavy and quite dysfunctional environment. He told me how he did it. Paraphrased: "It's easy. During each sprint, I work on the next sprint's work. Once it's complete I'll know how to make sure things match the work that's already been done and that way its always a bullseye and on time - because the work is already done.". Agile at that company was a joke to the people who got things done, and was a weapon used against people who didn't realise it in time. It sure generated a lot of metrics and stats though. I used to joke amongst coworkers that the company produced metrics, not products.

Its a nuclear option. Nobody wins. The site operator can adjust the difficulty as needed to keep the abusive scrapers at bay.

Case in point: cost breakdown from the invoice of an online order a few months ago (with the dollar amounts removed):

> Subtotal

> Shipping (Economy)

> Tax (Solano County Tax 0.25%)

> Tax (Vacaville City Tax 0.75%)

> Tax (Solano County District Tax Sp 0.125%)

> Tax (Solano Co Local Tax Sl 1.0%)

> Tax (California State Tax 6.0%)

Once your address is known taxes can be calculated. At what point is an after-tax final price to be shown? On an ad? On a targeted Ad? Once you reach the storefront based on unreliable geolocation? (which would be wrong for me, because geolocation bundles two cities here together as one) Once you create an account? At the checkout when you've specified the shipping address? As things tend to happen today, its usually only at the last step.

As much as I'd like to see it, I don't see much chance of improving the visibility of final prices without comprehensive systemic tax reform first.

The obvious quick solutions aren't exactly fair in the current US system. Imagine a "quick fix" of requiring the vendors to price in-a generic taxes for everyone. Just like with credit card system fees, "simple" fixes like that that benefit the residents of high-sales-tax states to the detriment of no-sales-tax state residents. While such a system would work for physical stores, they would get hammered if they had to prices on the shelves or signs that were higher than online prices.

As much as we all want a fair straight-forward system, I don't imagine it happening any time soon in the US. There are way too many unresolved zero-sum political fights and ideological differences standing in the way.

It certainly can be done (eg: Australia) but the circumstances there were very different.

It's been a while so I probably am misremembering the terminology, but I was always amused with the dynamic profile/feedback system that I always imagined would be more useful for a JIT code generator or JVM style runtime than a traditional compiler.

The amd64 architecture did have some interesting features that made this much easier than it might have been for other cpu architectures. One of which was the automatic cast of 32 bit function arguments to 64 bit during the function call. In most cases, if you passed a 32 bit time integer to a function expecting a 64 bit time_t, it Just Worked(TM) during the platform bringup. This meant that a lot of the work on the loose ends could be deferred.

We did have some other 64 bit platforms at the time, but they did not have a 64 bit time_t. FreeBSD/amd64 was the first in its family, back in 2003/2004/2005. If I remember correctly, sparc64 migrated to 64 bit time_t.

The biggest problem that I faced was that (at the time) tzcode was not 64 bit safe. It used some algorithms in its 'struct tm' normalization that ended up in some rather degenerate conditions, eg: iteratively trying to calculate the day/month/year for time_t(2^62). IIRC, I cheated rather than change tzcode significantly, and made it simply fail for years before approx 1900, or after approx 10000. I am pretty sure that this has been fixed upstream in tzcode long ago.

We did have a few years of whackamole with occasional 32/64 time mixups where 3rd party code would be sloppy in its handling of int/long/time_t when handling data structures in files or on the network.

But for the most part, it was a non-issue for us. Being able to have 64 bit time_t on day 1 avoided most of the problem. Doing it from the start was easy. Linux missed a huge opportunity to do the same when it began its amd64/x86_64 port.

Aside: I did not finish 64 bit ino_t at the time. 32 bit inode numbers were heavily exposed in many, many places. Even on-disk file systems, directory structures in UFS, and many, many more. There was no practical way to handle it for FreeBSD/amd64 from the start while it was a low-tier platform without being massively disruptive to the other tier-1 architectures. I did the work - twice - but somebody else eventually finished it - and fixed a number of other unfortunately short constants as well (eg: mountpoint path lengths etc).

I preferred touchid over faceid. Sure, there was always the SE option, but if I was buying a newer phone then it was going to be new one, damn it.

What pushed the needle in the upgrade vs repair decision for me was wear concerns on the nand flash. I've encountered plenty of stories of flash failures after the 4th, 3rd or even 2nd battery replacement. I never found a way to get a meaningful health check for iphone flash lifetime but I really didn't want to find out the hard way.

That was in addition to 5G vs LTE. LTE in our area is a quagmire.

You find out all sorts of bad DNS behavior when you run anything CDN related.

If you look a the old KSE work, the general gist was that if you were about to block in a syscall then you'd effectively get a signal-style longjmp back to your userland thread scheduler. You'd pick another thread and continue running all in the same process/task context.

There were many problems with what we did and how we did it, but the unavoidable fundamental problem at the time was that it inverted assumptions about costs of low level primitives. Important(TM) software was optimized for the world where threads and blocking were expensive and things like pthread mutex operations were cheap. Our changes made threads and blocking trivially cheap but added non-trivial overhead to pthread mutex etc operations. Applications that made extensive use of pthread mutexes to coordinate work dispatching on a precious small pool of expensive threads were hit with devastating performance losses. Most critically, MySQL. We'd optimized for hundreds of thousands of threads rather than the case of multiplexing work over a few threads.

It became apparent that this was going to be an eternal uphill battle and we eventually pulled the plug to do it the same way as Linux. We made a lot of mistakes with all of this.

Random example: the fuss about the facebook advertising/tracking SDKs back in the day. When apple started giving unique device IDs to each app, this cross-app tracking mesh imploded and they were screaming about lost revenue. Maybe you find billions of dollars worth of tracking to be creepy, maybe not. But if facebook had the option of getting that functionality and revenue back via an easy sideloading or some other frictionless alternative mechanism then the entire app ecosystem that was even remotely related to facebook tracking would have been off the app store in a heartbeat. Instead of being at the mercy of apple, you, and your extended tech-support family would have been at the mercy of facebook.

Apple is no angel, but the potential downsides are limitless. Instead of the facebook tracking example, consider partially or overtly malicious apps that your parents are now installing on their phones (as well as their malware-ridden PCs).

On the other hand, sideloading is a fairly low barrier for technically competent folks. Stuff like iResign and other tools have been around forever. You can grab any pirated/hacked/etc app package, sign it yourself, and sideload it via your dev credentials. But at least you don't have to worry about your parents doing that. Or facebook telling your parents to do that.

Anyway, that's a "for some reason" example. The readership of HN are not the target audience that the app store gatekeeping is there for.

(But don't get me started on fees/commissions/etc - that's indefensible IMO)

There's lots of ways if you have access to common cloud primatives (replacement root volume, etc) and have some creativity.

I did appreciate this post though because it's for a way I haven't used before.

I don't know if they've fixed it yet. I doubt it though - they were pretty aggressive in their assertion that violating must-staple wasn't a concern.

I feel it's more likely that the long game is ultimately about de-anonymizing the Internet.

This particular objective is a solid plausible explanation of so many initiatives over the last few years. Perhaps not full public de-anonymization, but at the very least to make it easier for things like CALEA to exist in these spaces as well. The public is constantly shown techniques in whodunnit TV shows where the good guys can instantly look up an IP address or other identifying log entry and associate it with a name/address/etc.

IMHO, the plan is to make Business As Usual untenable and make it cheaper and financially safer for tech companies to give in and identify everybody as a survival mechanism. When its safer to record a passport/realid/etc as a legal defense then at some point it'll be done.

After that happens then it's easy to plug in something like CALEA. The public is already being primed to accept it with the benefits being constantly shown on the likes of CSI/NCIS/etc/etc/etc shows.

Of course, from a profit perspective, it certainly wouldn't hurt that all this valuable user data that is being being compiled is finally cross checked and validated.

Or maybe I'm completely wrong and there's no ulterior motive and there's nothing more to it than politicians trying to be seen to be doing the right thing. Hah! I'm way too cynical for that.

My most recent position descended into a farce. The company had been reborn from the ashes of the old company. The product was 15 years old and had accumulated a lot of tech debt during the crash-and-burn of the previous company. There was a huge list of things that must be done, or the company dies.

However the new company spent 6+ months designing a top-heavy set of processes. After that, critical tasks from the "must be done" list that should have taken hours turned into a 2-6 week ordeal of following the process, meetings and busy-work. Generally a two week sprint to research, then put it on hold for a planning session, then another 2 weeks sprint to do the task.

When it's something that must be done no matter what, and as quickly as possible, then this is sheer lunacy. I'm talking about existential risks to the company.

I found out how the other engineers are coping with this. Just about everyone is actively deceiving management in order to get things done. It goes something like this: 1) just do the work during the research/planning sprints. 2) when the work is complete, write up your proposal and estimate time retroactively. 3) the engineers rubber stamp each other's estimates 4) during the time assigned, work on the next task instead, and commit the code at the end, right on time, exactly as predicted. repeat.

The company pivoted from producing a product to producing arbitrary process. People's performance was measured on the accuracy of their estimates, so the engineers designed their own process to hit the mark perfectly.

Unfortunately it's a good way to burn out.

Conflicting personalities makes resolving technical disagreements so much harder.

FWIW the threading in the network stack is one of the original major divergences between Open/FreeBSD PF. The way FreeBSD's PF works is within the context of FreeBSD's threaded network stack. FreeBSD PF is not "single threaded" in the way it used to mean.

I would really like to have the modern PF syntax/structure from OpenBSD in FreeBSD though. The unified rdr/nat/pass/block mechanism in OpenBSD is so much cleaner and nicer to work with.

* The Alpha bus architecture was used directly as the foundation of the Opteron and Athlon64 chips.

* The Alpha chipsets were used for Opteron/Athlon64 (eg: irongate family)

* A lot of the internals formed the foundation of Athlon64/Opteron, including the floating point system.

* A bunch more foundational work that I wasn't clear on was used. Alpha was far more closely related to Athlon64/Opteron than a lot of people realized.

I did the FreeBSD port to AMD64 and had a bunch of back-channel contacts with former co-workers who moved to AMD at the time. I had a steady stream of engineering samples, toys, documents and gossip. I still have a bunch of it around somewhere as souvenirs.

Aside: My favorite "secret" was REX32 mode. It was a special mode where the CPU allowed access to the 64 bit registers in a 32 bit OS, think 32 bit WindowsXP. It did not require the OS to be aware of this. Context switching of this extra state was bolted onto the side of fxsave/fxrstor in reserved areas at the time. This mostly intended to allow things like hot spots of nvidia drivers and libraries to secretly work in 64 bit mode on Windows XP. I was told that it made significant improvements to benchmarks. Officially it was just an engineering test feature. Sadly, it was removed - for a number of reasons.

Admittedly, Yahoo was an extreme case. It never solved the really building problem - the culture from the early days was to compile, ship and forget. Once a RHEL-6 package was pushed to our dist/yinst system (packages), it would never be rebuilt unless it was 1) necessary, or 2) It was time to try and figure out how to build it on RHEL-7.

A lot of effort was spent in the later years to try and address this (by burning the old tech stack to the ground), but the culture was pervasive for the longest time. If 10-year-RHEL didn't exist we would have been forced to address the building processes.

If it's hard or error prone, then do it frequently until you get the process nailed down.