pnt12

The point is that Ballmer is an adversary, and may choose the worst cases for binary search. As I understood, the algorithm in TFA holds against any choice.

As others said, if you don't expect adversary behavior in your data, it should be good enough.

Poetry does a lot of good stuff: lock file, dev dependencies (and other customizable groups), easy to use virtual env, dependencies pulled directly from git.

I do not recommend pip in serious projects, as it lacks the above. Here's things that I've seen:

- add dependencies and not save them in the requirements file - forget to activate cenv and install packages globally - different package versions across deployments due to absence of lock file - main dependencies mixed with dev dependencies

tl;dr: you keep the copyright but give inconditional rights for elastic to distribute your code, eg under different licenses.

This article is very forgiving towards tech companies, suggesting that users are techno phobic and the solution is to remove such labels.

My perspective: consumers have seen new tech emerge a thousand times and are favoring reliability instead of the flavor of the month new tech, especially when it was designed to sell instead, not to solve real problems.

This seems just like TVs, where more people long for dumber TVs with quality display - they are faster and more reliable than what the market of smart TVs is providing.

I think that's a very forgiving perspective.

Product teams are often wrong, and A/B tests can lead to inferior long term solutions.

As always, it's best to criticize the idea, not the people.

Does Nvidia negotiate deals for all gaming + crypto + AI companies to use their cards, or do they just provide good hardware + software that consumers want to use?

That would be the difference of an anti-competition monopoly vs just a monopoly.

Veritasium has a video on this:

https://youtu.be/rhgwIhB58PA

I accept them.

I've dealt with problems from python-dotenv and very much prefer it as a command than as a library.

As an example, once I changed a .env fikr and unit tests started failing. Digging deeper into it, and lots of code was checking for .env to load its configurations, and would break without it. I'd prefer this not to happen, as our tests were executing based on outside, not version controlled, configurations.

After removing dotenv as a library and using it only as a command, we were able to separate configuration and logic, and not have .env files affecting our unit tests - we simply ran the application with dotenv command, and the unit tests without.

> Generally, ad-tech and friends cares very little about small cohorts of users.

Sure, and it will keep being that way. But if this gets improved at the transport layer, seems like a win.

As an analogy, if buses are late because roads are bumpy and drivers are lousy, fixing the bumpy road may help, even if drivers don't change their behavior.

When I write code, I'm concerned about two things: - it does what I want - it's easy for others to understand it

If I'm doing red green refactor, the red and green phases are all about logic and constraints, but the refactor step is all about communication - I focus on making the code easy to read for others.

But if I'm reading code, I just want to know what it does.

Só, I didn't make a study, but I'd argue that writing code is more similar to writing natural language than reading code is to reading natural language.

That's a bit of a strawman: you're twisting the scope and arguing for it.

A more similar context would be: they ask Tom Hanks to create a voice similar to Woody, the cowboy from Toy Story . Tom Hanks says no, Disney says no. Then they ask you to voice their cowboy voice. It's obviously related: they tried the OG, failed, they're going for a copycat after.

But if never approached Tom Hanks or Disney, then there would be room for deniability - without mentions to real names, it would require someone to judge if it's an unauthorized copycat or just a random actor voicing a random cowboy voice.

It was a bad play from their part.

Companies want to have their cake and eat too: the code is free, but they're complaining there's no warranty.

If companies want better guarantees, then they should contribute more.

It's an interesting question, but I doubt it will happen. Companies gain even more (their free code is now more reliable) and FOSS maintainers lose more (now they're liable for the code they give away).

More questions: How can FOSS maintainer be compensated for this? Are they liable in every country? Etc etc.

Alternatives: companies could do public audits of specific software/library versions.

I can see his point: deleted code is really hard to discover. You can fetch it if you know it's there, but how do you find it in the 1st place?

With that being said, commented code is rarely useful and it cna be a liability indeed.

This approach is full of footguns.

Forget to install virtualenv? Have fun getting rid of packages in your global system.

Sub-dependencies? You'll have to think of a strategy for it. Most people don't and the reproducibility of their project suffers.

Developer vs production dependencies ? You'll have to think of a strategy for it.

And I think I'm forgetting one, but that's already enough.

Doing a security analysis of a car is a complex task that most laymen cannot do, so the argument for laws and compliance among specialists is quite reasonable.

Put it another way: if it's all market based, your choices in buying just get 2x more complex. Is this car easily unlocked? Do the brakes often fail? Can it resist a collision?

Or even another thought: since most people don't think about security, companies will flood the market with insecure cars. Want a secure car? That would be niche and cost you double.

Such a strawman. People get locked out of accounts with important stuff for them all the time.

Let's demand more of tech companies who have the means to do proper security , instead of bling user mistakes.

Could be a bribe: defend the interests of the companies, get some cozy jobs for your family in return.

I've had to dig through the history of a 5 year old project - it was much nicer when the commits were focused, the PRs has nice descriptions and even better if associated with ticket.

I will defend merge squash forever - low effort, good results. You do whatever you want in your feature branch, then merge squash. Everyone can do it. You want to split it in multiple commits? Then it probably should have been split in multiple PRs .

I need to write an article about this so I can just link to it instead of writing the same comment evrytime :)

Why?

I think the price point was meant to discourage people from paying. It's on par with streaming services, but with the content produced by the users. Do they get 200+ dollars in ads for the average user?

For example, I considered paying but I have a semi-inactice Facebook account which isn't worth that to me. I'm also not convinced of Facebook's integrity to honor the deal and not process the data anyway.

I'm not a fan of crypto as an investment, but I have no problem with this.

If you are investing with in multiple ETFs and are interested in investing,not owning, in BTC, this makes things simpler - you buy the ETF, the exchange buys the BTC.

If it reaches a point where everyone is just holding for returns, then it could be a timebomb until it all crashes. We could be there already.

This is why firing without cause should never be accepted - the result is straight out of 1984 where people get scared about expressing their thoughts , as they can lose their jobs and health insurance for any reason.

It's much safer to lay low and don't say anything too provokative, but that's a danger to a healthy democracy.

That will be uncommon.

Very well put. This is the work flow which has worked best for me over different teams.

An opposite which I could accept is asking people to carefully rebase their drafts, but I see it as a higher effort with a bigger risk of screwing up, with a dose of bikeshedding an additional topic, the commit history: "why do you split in 5 commits when 2 would be enough?"

I guess you can keep the drafts if you don't delete feature branches. But I don't see it as extremely useful, unless it's a very talented individual AND very methodical with his commit history.

Maybe they test (with code or manually) different commits and then point out which one introduced the problem in the ticket system.

Could be useful but parent mentions a megacorp, so maybe it's just some bureaucracy or ball-breaking.

I don't see this technique applied too often. I see more often:

- reading the affected code - reproducing the problem step by step with a debugger

Which I guess works for all kinds of problems and not just for regressions, therefore people are more used to it?

Unless we're talking about different workflows, squashing works great.

In my team, we merge squash our PRs, having a guideline that they should be a small increment. Here's what happrns:

- when you checkout a commit, you are guaranteed to have a version that was reviewed by a person and validated by ci/cd - most commits have chsnegs with substance, instead of "log", "debug", etc

Without squash, a person can push 3 commits to a feature branch, ci/cd says the last commit is OK, it gets merged, and you may get 2 commits that don't compile or cause a very basic runtime error due to some typo or whatever.

(not that it could not be solved with due diligence, but that comes with higher effort too)

How do you assure working commits and avoid noise without either squash or rebase?

Technically, licenses are not free/open source if they restrict usage.

Some have created licenses against commercial or unethical uses but they are not widely used in software, as they open a can of worms - these restrictions are subjective and as such hard to enforce.