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.

It's not that simple. Disagreements are one thing, but the real reason was the conflict and drama that happened when things didn't go his way. The threading approach just happened to be a really good trigger for those conflicts.

Conflicting personalities makes resolving technical disagreements so much harder.

DragonFly and FreeBSD have radically different ideas on how multithreading should work. (Understatement of the century right there!)

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.

That sort of thing still happens with FreeBSD, even recently. Find a kernel bug, spend days tracking it down and fixing it, contact a maintainer for feedback before submitting it, and then they slightly reformat it and commit as their own work.

You are correct. In spite of the carve-up of the company, many designers ended up at AMD. I'm a bit fuzzy on the details and it is second hand information, but as I remember it:

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

It's one of the things that ground Yahoo to a halt. We spent years migrating from RHEL-4 to 6, then RHEL-6 to RHEL-7, and by the time the projects were pretty much complete, the next sunset was approaching. My cynicism comes from seeing the bad things that "Enterprise Linux" enabled there.

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.

There is another problem that wasn't covered in the article. The 10+ years of stability leads to behaviors and outcomes that remind me of the long-lived SSL certificate problem. Updating is done so infrequently that the "how?" is forgotten. As the 10 year support limit approaches, most of the old team members who did it last time are gone, tech debt is through the roof, few people know where everything is or how to build it, and so on. Enterprise Linux "stability" enables all sorts of bad behavior if your company is inclined that way.

LetsEncrypt did us a huge favor by forcing automation vs having the guy who knows how to update the SSL certs every 4.9 years and left 6 months ago. I'd like to see the RHEL stability model go away too and force people to complete their automation and solve the problems of being able to rebuilding on demand - and actually doing it.

(I know, most HN folk are well disciplined but there are a lot of corporate cultures that are not.)

"carp" should also be included in discoveries alongside pfsync. carp functions like cisco/juniper/etc VRRP to enable real-time failover. With pfsync being a stateful firewall a lot of care needs to happen with failovers. carp + pfsync allow you to run multiple hot pfsync firewalls that have synchronized state and have near-instant failover without state-related hiccups.

We use pf+pfsync+carp extensively over in FreeBSD.org as well. It's good stuff!

It was all truly unfortunate. But sometimes there are no clear right answers - but you have to make a choice between multiple bad options. When doing nothing isn't an option either then you have to make a call as to what you think the least terrible outcome will be and history will be the judge as to whether you were right.

Similar issues contributed to there being multiple *BSDs. It's never that simple of course, but it was certainly a part of it. Technical/ideology and Personality all play a part.

Heh. I can't blame them for doing this, but not telling people what's happening (and why) was the big mistake.

People generally want their gadgets to be as lightweight as possible, cheap as possible, last as long as possible, and be reliable. There's tradeoffs in balancing those. eg: overbuilding the battery to make the device run longer in the face of degradation adds weight, size, and cost. Somebody has to make a call on where the balance should be.

What nobody really talks about in the context of device longevity is wear levels in the onboard flash. A battery replacement or three doesn't extend that clock. It's pretty good but it doesn't last forever. This is more of an issue on devices with smaller amounts of flash storage with a lot more storage churn.

The cynic in me suspects that they probably tried this and discovered that they will lose a percentage of logged-in accounts and how much that costs their revenues/bottom-lines.

Seriously though, even apple does this - where they periodically ask you for your pin/password on phones with fast biometric logins every 1-2 weeks as a memory refresher.

For google: I think they should do a memory refresher too. Once you've confirmed that you remember it, they can stop bugging you for some time. And if a logged-in user can't remember it, then don't log the user out, give them time to save important things.

I'm having flashbacks to some Alpha machines that were donated to FreeBSD.org in the early 2000s for an Alpha build cluster.

They came from Microsoft, although perhaps indirectly, and the drives had all sorts of NT/Windows labels and IIRC had not been wiped.

I have photos of the machines but I don't recall what happened to the drives. I know they were put aside.. somewhere...

The machines were eventually replaced with systems (indirectly) from Pixar. The original machines are long gone.

Agreed. If that's all it cost them then they'll consider it a bargain!

I remember going over every page and every Ad when magazines like this were the news pipeline for what was going on. Before Usenet, Internet etc, that was pretty much it. Dial-up BBS systems were more local than anything.

One thing really hit home with this magazine - the sheer vibrancy of the industry back then. Just about everyone was out there and trying to claim a niche in a corner somewhere. It ranged from somebody with a side project buying ads in Byte or the local users group, through small businesses, and some big ones.

And then came the IBM PC. And then the internet. Sameness happened. There doesn't seem to be anything left that remotely resembles the nascent computer "industry" of the early-mid 80s (except perhaps the tech hubs in China).

Another thing that struck me: writers freely provided their home address for mail replies. Imagine that today?

Meanwhile, one of the most annoying holdouts on the service side is github.com - I've had a collection of v6-only systems for years and github seems to be the one recurring thing that requires bolting on kludge of some sort.

Come on github! It's not that hard!

It's not just BBB. This description could apply to a good number of chain stores these days. There are exceptions but this seems to be an increasing trend. There are ghost town stores everywhere you look.

If I make a trip to (for example) Target, it feels nothing like Target of 20 years ago. The chances are good that they don't have what I hoped to find there. I'm getting used to being regularly disappointed and am learning to plan around waiting for an Amazon delivery.

This seems to be a vicious circle. The thing stores had which Amazon didn't was that they used to have a decent selection of things you could get "right now" and they're giving up on that niche to try and compete on price. I don't see this ending well.