HN user

jjayj

69 karma
Posts0
Comments34
View on HN
No posts found.

There's no garage, and the only driveway-facing outlet is at the front door - opposite where my parking spot is allocated (an extension cord would have to go under/through the landlord's cars.) I have to drive 60km to work every day.

Only laws (accommodate EVs and/or WFH) or spending time sitting at a gas station will help me here. No landlord is interested in accommodating an EV unless it's a net benefit to them (and thus a net negative to me, who already spends 40% income just to have a place to work.)

The other option here is "pick an OS and when necessary install newer packages from source."

We've been doing this for a long time at my current workplace (for dev containers) and haven't run into any problems.

Android does provide a WiFi suggestion API [1], but it has several limitations and doesn’t behave quite as expected.

Can you expand on this? I read the linked doc, and it looked like a separate API should be used to used to "persist a network connection" (my words), but as someone with no Android dev experience there don't seem to be any obvious limitations.

You did mention in another reply that only certain root apps can do [what we expect]. Is there a link where I can learn more about that?

Just to add some (unprovoked) additional info here: I'm a 26 year old Canadian. We covered early Canadian history, abuse of the aboriginal peoples of Canada, war with America, and WW1/WW2/the Holocaust.

I don't think we were really taught at all about European/Asian history or the Soviet Union. I think I could have taken some classes related to those in highschool (secondary school), but for anyone working towards a non-history bachelor's degree those courses were generally not something that you could fit in your timetable.

We are multi-cloud, multi-region, multi-environment, multi-deployment with hundreds of AWS accounts.

This is split over hundreds of microservice repositories, each of which maintains its own Terraform.

We don't read state from other Terraform deployments, and use published reusable modules when convenient and a tfvars file for every deployment.

At this point I can't imagine doing Terraform any other way.

We ran into this, informed our users to reinstall Docker (we use Homebrew), and seemingly have had no further issues. I guess we're the minority?

I would be more inclined to blame this on Apple than Docker, but I haven't looked too deeply since things are working for us. Curious about you folks' opinions.

Will Anderson, another Scrabble champion/grandmaster, uploaded a video talking about Nigel's win here. The win is a lot more impressive than memorizing bingoes - Spanish scrabble has different letter distributions and point values, resulting in different metas. He didn't just memorize the Spanish Scrabble dictionary - he learned how to play Spanish Scrabble and dominated the first Spanish tournament he participated in.

Definitely worth a watch if you're interested in Scrabble at all: https://www.youtube.com/watch?v=6RvNxkQ6Bgs

I'm more inclined to invest time in git itself.

This is fine until you're working with hundreds of other developers. I believe the reason solutions like this exist is to abstract git away from most devs, because in (my experience) many enterprise devs have only rudimentary git knowledge.

Sure, the devs should "just learn git" - but the same argument applies to a lot of other tech nowadays. Ultimately most folks seem to want to close their ticket off and move to the next one.

Git submodules and git subtrees generally do not fit my org's needs - we have internal tooling similar to this. Happy to expand on that if you have questions.

GHES is a massive monolith running dozens (hundreds?) of services in Nomad, so it's not surprising to me that GH has a hard time supporting it and wants folks to move away from it.

I'm tired of slow, risky, late-night upgrades to the appliance. I'm tired of sending support bundles and being told to run a customized string of MySQL commands to resolve peculiar issues. I'm tired of checking the roadmap and telling folks "yes, they announced that feature, but it won't be available to us for at least 12 months." I'm tired of a feature eventually being in the GHES release notes, only for GitHub to have made a mistake and it not be available for another two versions.

We're moving to GHEC. I'm concerned about the semi-frequent outages there, but we're not running HA GHES so it has become a liability for us.

We have looked at GitLab in the past, but I wasn't involved in that process. Generally though:

- Enterprise support is very important to us - Migrating thousands of repos and training hundreds of devs to use a new VCS is a huge and expensive task - We have custom integrations with GitHub that would need to be rewritten as well

I run an on-prem GitHub server. New features come 6-18+ months behind Cloud for the most part, our reps are always trying to get us to move to Cloud, and new features are often broken for weeks/months even after being released for on-prem.

Yeah. I had the beginning of some thought about C vs assembly, but that is already well discussed. This seems like another iteration of that topic to me. It has inspired me to try to replicate a Dockerfile using bash and these "lower level constructs" at some point.

The article may have been more convincing if it contained examples of Dockerfiles and an equivalent shell script. There were some links that I think went into this, but they looked pretty verbose so I didn't look into them tonight.

Does anyone here have any experience with having an entire org of (hundreds of) devs use these lower level features rather than Docker et al? In a k8s-centric organization, is this feasible at all?

Past 99%, what does "more accurate" mean? I think it will vary from person to person and use case to use case, which is why I personally don't foresee a world where an LLM or any form of AI/ML is ever perfectly accurate.

I'm struggling to think of any medium that has ever reached 100% accuracy, so to target that for an ML algorithm seems foolhardy

I feel that the vast majority of folks would claim they'll 'never buy anything from ads'. Isn't one of the main benefits of advertising purely brand recognition?

I'm unsure how I feel about the 'zero chance to ever serve vast majority' argument. I use uBlock and Sponsor Block, but recognize that that has an impact at scale. I guess that argument kind of feels to me like "your single vote doesn't matter." For a few hundred or thousand folks, sure. But what if 500k people start using it?

My completely ignorant and uninformed opinion:

If the vast majority of folks started skipping ads, and ads thus no longer had reasonable conversion rates, companies would stop investing in podcast ads and many podcasts would stop being produced.