awolf

Doctor, church, shooting range, protest. ICE was one item on a list. Build the infrastructure and it stays built for whoever’s in charge next.

Trying to discredit my substance based on a single of many examples tells me you're not arguing authentically here, nor elsewhere in this thread. We are failing to be productive past this point.

Yes, same outrage: it’s most of what I’ve worked on for twenty years. But “you’re already surveilled” isn’t a defense of Flock, it’s an argument for less surveillance everywhere.

Volume isn’t the distinction that matters, who holds the data and what is possible as a result is. Meta can sell my movements to an advertiser. It can’t pull me over, detain me unjustly, or hand my neighbor over to ICE. With Flock, police aren’t a downstream buyer; they’re the direct customer.

And “you already gave it away” is no longer good law. Chatrie v. United States (2026): Chatrie had opted into Google Location History, and the Court still held that disclosure to a third party doesn’t forfeit your Fourth Amendment interest.

Worth noting where we started, though. Two comments ago there was no plausible connection between public roads and privacy. Now there’s one, it’s just smaller than Meta’s. I'm really glad you have had this anparently eye opening moment here on HN.

It's not about your vehicle being seen in public at a single point in time, it's the fact that this system captures everyone's patterns of life. School, doctor, shooting range, church, play, protest. When, when, how often. All tracked and packaged up in a commercial database, without warrant or justification.

If you happened upon me on a public street, I'd say "that I'm here on this street now is not private information".

If you installed sensors across the entire city with 2-5 block resolution and could tell me everywhere I have been in the last 30 days (and hence where I'm liable to be tomorrow), I'd say "you are grossly violating my right to be secure in my person against unreasonable search - this is wrong".

Coal has a much worse heavy metal issue than Nuclear.

yes we're talking about living in today's world but... off the grid.

no one said "historical reenactment"

?

One patten I've seen to address this is to define a "plugin architecture" where disparate components are integrated into the main system via fixed "sockets". The sockets themselves are generic as is the glue code that attaches plugin and socket.

This does create a lot of boiler plate, but that boiler plate is predictable and uninteresting, and a good candidate for code generation.

Both added in iOS 14.

I guess Apple's not "full of shit" anymore.

> But, wow. This is beginning to look pretty scary.

This is the main benefit I see of having our government take these measures: making people like you realize THIS IS SERIOUS. It has "looked pretty scary" for almost two months. And no one has taken it seriously. And now we're here.

sure, was just matching what the author said in their example. 100% agree no need to use obscure words

yes

> If the first line of a commit message is a title, it changes the way you write it. It becomes just some text to introduce some more text, without any stress on the information density.

I agree with the author that commit messages should optimize for information density. However the example they provide does a poor job of this:

> This is a smart synopsis, as information dense as possible.

"This is a" is the type of thing that should never appear in a commit message as it could apply to EVERY commit message. Synopsizing is the action, but doesn't indicate what is being synopsized; one of the most important facts for someone to understand what is happening here. Finally "as information dense as possible", again should also be cut as this is telling us HOW not WHAT (and ironically hurts information density).

Were I writing this example it would be:

  Synopsize how to write a commit message

---

I led an initiative at my current company to enforce all commit messages start with an imperative verb and be less than 72 characters. Some people hate it, some people love it.

Aside from standardization, the primary reason to do this is the imperative mood leads to the most concise sentence possible. By leading with the action, the most natural thing to do next is to talk about what is being acted upon. Unnecessary words are dropped and the most important facts are emphasized. In short it forces the author to get to the point.

  [Act] upon [some aspect of the code]

e.g.

  Add user login link on home screen
  Refactor authentication into separate classes
  Lint PR titles conform to standard format

I definitely wear my Series 4 every night for sleep tracking comfortably. Charging for the 20 minutes I'm in the shower is enough.

The article is comparing year over year. July 2019 to July 2018.

The Equifax link leads to a form where you submit your social security number and birthdate. Cool.

Rather than `git add -p`, I suggest creating a second clone of your repo, staging your foundational refactor changes in the second repo, creating and merging your commits there, and then rebasing your working branch.

This makes sure you can fully test your refractors and that their change sets stand alone.

Travis Kalanick, Uber's CEO, made public statements indicating that Uber must work with the Trump administration. Four days later Uber stepped up as scrubs while the rest of the New York's taxi service protested Trump's deplorable racist actions. It's hard to pretend this is a coincidence.

>for example he published papers previously where the evidence led to a different conclusion

I did not know this. Could you share the papers you're talking about?

Or.. Both?

This will vastly outstrip competing analytics services because Apple exclusively has visibility to App Store browsing patterns.

I agree with you 100%. MBTI is garbage.

but I hope you can still appreciate the irony of your post Mr. Skeptical

That's silly. The fuel and operation costs are way too high.

>better-informed parties find it extremely difficult to think about problems from the perspective of lesser-informed parties

Reading this made me think of poker. Calibrating to the skill level of lesser players is often very difficult for intermediate and lower-advanced players. Being able to synthesize the less sophisticated thought technologies beginners are using is surprisingly difficult. Failure to adjust often leads better players to play incorrectly against newbies. Anyone who has experienced the frustration of beating medium/high stakes cash games only to lose in home games with your friends for 1/1000th the stakes will know what I mean.

Uh, fine. Sure, some of the rejections may be appropriate. But the situation with Drafts and PCalc are still very valid examples of problems with Apple's policies.

That Apple could come and shit all over your hard work is simply a risk factor to consider amongst all other factors a developer should be looking at when deciding what platform to develop for. All platforms have drawbacks and advantages. It's just a matter of picking your poison.

I'd be interested to hear why you think the cons outweigh the pros of developing for iOS. Universally, across the board for every software developer? Really?

I think this is the list of arguments I saw back when you originally wrote it. Ever since then, I wished I dug into this deeper with you as it's been an open thread at the back of my mind. Even though this may not be the right place for it, I'm going to go ahead and respond point by point.

* It forces you to negotiate with clients in the worst possible numeric domain: where small deltas to proposed rates disproportionately impact the final cost. (This is a really good point and something that I will consider moving forard. I can see that higher effective rates may appear more palatable to clients if quoted on a per day or per week basis.)

I've categorized my feelings about the rest of your points:

The [HOW DOES BILLING HOURLY DO THIS] points:

* It positions you against the lowest-quality cheapest providers. (I charge a very high hourly rate, clients are happy to pay it.)

* It misaligns your incentives, so that you're penalized for doing a better job. (The times I accomplish a difficult task very efficiently are averaged with the times what appears to be a mundane task turns out taking much longer.)

* Not to mention: it generates more invoices. (I bill bi-weekly. I imagine I'd want to do the same no matter what unit I was using.)

* For that matter, it inclines your projects towards the small and away from anything ambitious. (Huh? What's wrong with "I expect this project will take 4 months of me working at 30/hrs a week and this hourly rate"?)

* It impedes your own flexibility, so that you tend to miss opportunities to interleave projects or for that matter take an occasional long lunch. (I typically tell clients that I'll put in 3hrs of work/day on their projects. It seems like my billing gives way MORE flexibility, not less.)

* It forces you to account for every waking hour of your day in a way that daily rates don't, when we all know that only a small subset of your work hours are truly productive. (See previous point: I'm never of the hook to provide a "full day". Some days I work more, some less.)

The [HAVING AN OPEN AN HONEST DISCUSSION ABOUT THE SOFTWARE DEVELOPMENT PROCESS AND WHAT EXPECTATIONS ARE APPROPRIATE AND WHY I FEEL UTTER TRANSPARENCY IS KEY FOR MUTUAL UNDERSTANDING] points:

* It totally hides the cost of ramp-up and ramp-down (if you think clients push back on daily or project rates, wait until you charge them for 2 hours of "getting in flow"). (My clients do not push back on this because I explain how very necessary this type of work is up front.)

* It conditions your customers to take a fine-tooth-comb approach to project plans and invoices. (If they're fine-toothing, that's fine. I can't really tell, it doesn't affect me. I've had a single client ask me a single time for clarification on an hourly line item in the past four years. It wasn't a big deal.)

The [I ALWAYS PRECISELY TRACK TIME ON EVERY PROJECT I WORK ON BECAUSE IT HELPS ME IMPROVE AT ESTIMATING, WHICH I'M NOW EXTREMELY GOOD AT] points:

* It forces you to be vigilant about time tracking lest you accidentally undercharge customers.

* It inclines you towards finicky accounting, the kind that charges a customer for a 45 minute phone conversation.

The [I DON'T UNDERSTAND WHAT YOU MEAN] point:

* Not to mention, with virtually any client worth doing business with, you (the consultant) are much more sensitive to the cost of a project than the customer is; it is a small miracle that the customer can get a programming project completed at all without potentially hiring and then firing 3 different people. So why is all the burden on you? Why is any of the burden on you? Key consulting idea: it's not the customer's money they're spending. (What burden do you mean? The burden of tracking time? The burden of estimating?)

The [HOW IS THIS DIFFERENT EITHER WAY] point:

* It obscures the final cost of projects in ways that make clients defensive, so that their immediate thought is "oh shit this is going to add up to lots of hours we better be careful".

The [I REALLY DON'T THINK GIVING FREEBIE TIME IS IMPORTANT FOR CLIENT RELATIONS IF YOU SET EXPECTATIONS APPROPRIATELY] point:

* It makes it harder for you to reasonable toss freebie work to your best clients without damaging the expected value of your time; for instance, I can cab over to a client in Chicago and spend 2 hours looking at a design with them for free without creating the appearance that my bill rate is arbitrary. (Why would the ability to offer free work inform the structure I put in place for billing?)

I hope I'm not coming off as disrespectful, I do really appreciate the time and care you put into HN. It's just that, if it's possible for it to happen, I'd love to be convinced to change my billing structure to something that works better for me.

I'd really like to hear more discussion around this "don't bill hourly" concept. I'm 4 years in to a successful, solo freelancing career and this advice still doesn't click for me. I've billed precise hours for every one of the 20+ projects I've taken on.

What am I missing?

It really seems like your complaint is more with the types of movements recommended vs. the duration.

At least.. it should be: I've seen and done many exhausting HIIT/Crossfit-style workouts that last only 7 minutes yet wipe out even the most athletic people.

E.g.: here's a 3 minute workout https://www.youtube.com/watch?v=pz9pXeLsmQk

Less RAM more battery life. Less RAM bigger margins.

Two pretty good reasons.

The position that saturated fat is causative in heart disease is not the default position. If an idea is going to generate prescriptive advice it should come with ample supporting evidence.

Despite this we've been strongly indoctrinated with the idea that fat == unhealthy. It has caused us to change our behavior by avoiding foods that our parents and grandparents have been eating down through the generations. We've moved away from the default "balanced diet" on bunk data.

I define healthy fat as meat which came from a healthy animal. I define a healthy animal as an animal that was raised in accordance with its species' natural diet and lifestyle.

Grassfed beed, pasture raised pork, wild caught seafood.