numbsafari

The direction of political winds shift over time. An organization like the PSF cannot assume an open-ended liability like that. DEI today, but what tomorrow? As we have seen, political leadership in the US has shown itself to be unreliable, pernicious, and vindictive.

US leadership is undermined by the politicization of these grants. That is something that members of this community, largely a US-based, VC-oriented audience, should be deeply, deeply troubled by.

Yeah, this all makes sense if the intention is to change the name of the device.

Netflix (the service) has an app named Netflix. You access Netflix via Netflix on... XYZ. Same goes for basically every other streaming service.

So Apple TV the service on Apple TV the app makes perfect sense if you are thinking about accessing their streaming service via other set tops where Apple TV the app is available.

My guess is that the Apple TV set top will be renamed to something else, perhaps "Apple Home".

Then it would be "Access Apple TV via the app on your Apple Home device" and the merging/conflation of "Apple TV subscription via the Apple TV app" will make perfect sense the same way you would say "Access Netflix via the app on your Apple Home device".

My guess is that "tvOS" will be renamed "homeOS" to go with it.

They certainly move fast and break things.

This is awesome. Only thing that is missing is a place for me to ask a question from Kagi Assistant about the current story I am looking at, using the story as part of the context of my question.

Don’t buy anything from Assa Abloy, local or not.

How about I just want to access my files remotely after a reboot occurs without having to get to the device at my house?

Agreed, though… MacOS isn’t a proper multi-user system and X is Not Unix…

Your classic bug is being used as justification to destroy the careers and lives of tens of thousands of people. Read the room.

Clearly there are some issues with ghosting?

I bet the clay tablet will be just fine. No word on moldy cards.

Pedigree of the team and a believable project plan.

Often times money will be raised at certain valuation and terms, but the cash is held in escrow (effectively) until milestones are hit.

The investors will do their due diligence on the feasibility. It’s a high stakes, high return game (if you succeed). Look around you… any physical device you see is basically funded the same way.

He is (and was) literally the CEO.

Yeah, he can give whatever title he wants to his subordinates, but the "CEO" of GitHub has been a mid-level VP for quite some time.

Why are so many cults founded on fear or hate?

Because empathy is hard.

If you just need a hosted git server, maintenance is mostly just making sure you have a proper storage/backup strategy in place.

If you want to self-host a code forge... start here: https://forgejo.org/docs/latest/admin/upgrade

Contact Satya Nadella.

It's a great time.

Yeah, especially if you deploy it on Azure...

... no mention of golang and minimal version selection?

https://go.dev/ref/mod#minimal-version-selection https://research.swtch.com/vgo-mvs

Instead of a "lock" file, go includes a "sum" file, which basically tells you the checksums of the versions of the modules that were used during a build happened to be, so that you can download them from a central place later and ensure you are working from the same thing (so that any surreptitious changes are identified).

> seems like a really confusing question

Agreed. ‘sendOnce’ implies something very specific in most async settings and, in this interview question, is being used to mean something rather different.

How does it compare to a wet rag with tongs?

I work with batch oriented store and forward systems and they definitely push data in batches.

As in urns for ashes, not Universal Resource Names.

I am imagining putting this in my toddlers bedroom and how much delight he would derive from and how much chaos would ensue.

Ah, my precious…

Hiring a bunch of recent college grads to build your startup is fun. They're great drinking buddies and they make you feel young again. They'll inefficiently work around the clock, sleep at the office, and treat it like their mom's house, and make you think you're a big, important boss.

Coming in as a gray hair to fix their disaster definitely pays the bills.

With the referral to the US attorney’s office, he actually might.

Consider how painful that is going to be for Apple, and Roman, with how the current administration is abusing the DOJ.

The repercussions of this could be huge.

... and that industry led consortium will have a board all paid princely sums, and an executive leadership team that is conflicted to the hilt and paid kingly sums, and they will charge exorbitant rents in order to keep the lighthouse lit.

There's flaws with every approach, but I much prefer the approach where this sort of thing is treated as a public good, rather than as yet another soon-to-be walled garden.

I have completely soured on Dockerfiles. I view them as anathema.

The supposed "caching" of layers really doesn't work in practice unless you add a bunch of other infrastructure and third-party tooling to your build process. Getting truly incremental and reproducible layers into your build process is non-trivial, and the Dockerfile approach fails to take advantage of that work once you've done it.

This is what I've done for years: doing app development using the .test TLD, and .internal for, well, internal services that are more like "production IT".

I've had nothing but trouble with .local and .localhost. Specifically, .local is intended for other purposes (multicast DNS) and .localhost has a nasty habit of turning into just "localhost" and in some cases, resolvers don't like to allow that to point to anything other than 127.0.0.1.

More recently, I've stuck to following the advice of RFC 6762 and use an actual registered TLD for internal use, and then sub-domain from there. I don't use my "production" TLD, but some other, unrelated TLD. For example, if my company is named FOO and our corporate homepage is at foo.com, I'll have a separate TLD like bar.com that I'll use for app development (and sub-domain as dev.bar.com, qa.bar.com, and maybe otherqa.bar.com as needed for different environments). That helps avoid any weirdness around .localhost, works well in larger dev/qa environments that aren't running on 127.0.0.1, and allows me to do things like have an internal CA for TLS instead of using self-signed certs with all of their UX warts.

For "local network" stuff, I stick to ".internal" because that's now what IANA recommends. But I would distinguish between how I use ".internal" to mean "things on my local network" from "this is where my team deploys our QA environment", because we likely aren't on the same network as where that QA environment is located and my ".internal" might overlap with your ".internal", but the QA environment is shared.

Mentions Buck, but no mention of Pants or Please.

I think "certified unix" is meaningless to most people who use "a unix".