darkhelmet

I have some issue with how some of these are represented. For example, syncthing has an explicit opt-in request for telemetry / analytics. The suggested setting change is something entirely different - a call to ask what the latest version is. Granted, that server could log your IP address but that's no different to how it uses the relay and discovery servers that are also run by the same people - those could log the same way.

.. 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.

Agile, as implemented in every big company that I've worked for, was a lie.

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.

For what it's worth, upcoming iOS 26 has a new screening feature. The idea is that calls from numbers you don't have a connection with will be asked to briefly identify themselves and why they're calling. It'll show you this text and give you the choice to block/send-to-voicemail/ignore/accept.

You're missing the point. The approach is block anything that doesn't execute the javascript. The javascript generates a key that allows your queries to work. No javascript => no key => no content for you to scrape.

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

Right up front: I agree. But, implementing this will be an absolute PITA because so many other things are systemically broken.

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.

> "how are you supposed to write a compiler for this?"

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.

Every time I see people struggling with this, I am so incredibly glad that I forced the issue for FreeBSD when I did the initial amd64 port. I got to set the fundamental types in the ABI and decided to look forward rather than backward.

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 had two apple US$49 battery replacements both of my iPhone 8 phones before my wife and I jumped to a 14 pro max.

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.

This is more common than you might think. I have encountered cheap home routers that have dumb dns proxy caches on them that simply cache everything for a fixed time period. I heard of one that simply flushed its cache at the same time every hour.

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

We took a shot at doing ultra-fast kernel threads on FreeBSD a few decades ago. For various reasons, it was reverted and removed a few major versions later.

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.

Playing devils advocate for a moment: One reason why is that many app developers truly do not have your best interests at heart. Taking heat for being a gatekeeper sucks, but the downsides of the alternatives are potentially limitless.

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)

One of the things I've done in the past that is quick and easy is to use grub to chainload another bootable volume. Scp an iso or other disk image over, chainload to that, run the installer inside it as though it had just been pxebooted or booted from a flash drive. If you can netinstall from there, then you're good to go with the OS of your choice.

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.

cough nginx. Nginx would start up and serve TLS on must-staple certs .. before doing the staple setup. ie: any client that validated that a must-staple cert had a stapled ocsp ticket would fail for the first few queries after nginx startup.

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 don't think this is really about protecting minors, or hurting big tech, or scoring some short term votes, or anything like that.

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.

- prioritize process over product

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.