This is about getting wholesalers to pay them to take the data about where they source their stuff and who they sell it to at what rates so Amazon can replace their step in the chain as well.

No, it's more about how teams work. Teams have a scope. They don't typically go beyond that scope. So if my team owns the Foo and Bar modules, I work on those. But if there's little important work on Foo and Bar, but a lot of important work to be done on Baz, it's generally organizationally difficult for us to work on Baz. Typically we need to be lent out by our manager and seconded to the other team. Which can be a lot of red tape and politics.

Now if you're imagining some alternate world where programmers an be moved at will- then we're already one big team instead of multiple small teams.

And no, a smaller team doesn't win every time. If it did, then then smallest team possible is teams of 1 and we'd all do that. There are sweet spots, which depend on the organization, the work to be done, and the importance of that work. For some that's bigger, for some smaller. I've definitely worked on teams that were both too small for the work, and that were too big.

They can, under some circumstances. If the scope of what they work on is too small to fill the team's feature set. Or if the work they would be doing is significantly less important than other work to be done, having them in one large team makes it easier to move to more important work and can get critical features built faster. In that case it may not be overall more work done, but it may move the important stuff quicker. If larger teams weren't useful on some level, we wouldn't have teams at all- we'd all be individuals.

They're one of the 4 biggest stock brokers in the US. If you aren't trolling, you're showing yourself to be really ignorant.

In the end- good engineers with sufficient experience and support will get stuff working with any methodology. Bad ones or ones insufficiently supported will fail with any methodology.

There are some things that agile works well for, but it's really limited to domains where you can quickly build something tangible for feedback and you have stakeholders willing and able to give frequent feedback. UIs are a good example. It's a horrible fit for anything that requires actual research, or that can't be shown to low technical knowledge customers frequently (in other words anything that actually needs weeks or months of backend work, algorithm writing, or infrastructure to be written).

The problem with that is the skills needed to manage and the skills needed to do real work (let's take programming as an example) are pretty distinct. Someone can have both, but they tend to have one or the other. Forcing those without the skills to do the practical work into doing it doesn't actually help the team, it just slows everyone down. And if they get on the critical path of any project you can be royally fucked.

There are a couple of ways to solve this problem:

1)Larger team sizes. This can work if the team owns enough to keep everyone busy, but it can lead to effectively being independent subteams calling themselves one team while being inconvenienced by each other.

2)Each manager managing multiple independent teams. This can work if it doesn't overload the manager. The biggest problem is when the manager decides one team is more important and doesn't support the other(s) enough. This works better the closer the teams are, as it requires the manager to know fewer sets of collaborators and politics

"Hey, what's the big deal? We used to append 'P.S. I love you. Get your free email at Hotmail' to every outgoing email way back in the day, and no one ever had a problem with that..."

Welcome to the all-new eStop! We know you have concerns, so let us put them to rest straight away.

The site will not change. We respect the investment you've made in learning and navigating the site. However, if you're feeling curious or adventurous, feel free to check out our [new site design prototype]. (This design will become the default landing page in mid-2027; the old site UI will enter maintenance mode for only the most critical bugs.)

To thwart LLMs and other bots, new default limits on bidding have been imposed. Accounts may only bid on a given item no more frequently than once every 20 minutes. If your circumstances require more frequent bidding, have a look at our [eStop Pro Membership Plan] for only $9.95/month (billed annually; no pro-rated refunds), which will allow unlimited bidding frequency. And for members who want to have more than 20 items on sale simultaneously, take some time to review our [eStop Bulk Vendor Programs], charging only 25% of gross sales, or $3600/year + 20% of gross sales.

And to help with "doomscrolling" for that one specific thing you're looking for, we've also partnered with Anthrop\c and X's Grok to help curate your buying experience, surfacing the items most likely to interest you.

(All terms are subject to change without notice.)

I get sick after 10 minutes last time I tried it (a few years ago). It's not anywhere near solved. Of course I have no desire to try the new versions, because even if it was solved it doesn't actually make anything useful better.

(a/k/a Innovation Subscribers Don't Need)

It still amazes me that, as late as the 1990's, and well after 56kbit modems were prolific, ISDN was being offered up by the ILECs as "broadband," at metered rates that made Ma Bell's long distance charges look like spare change.

Happily, it wasn't too long before ISDN was put out of everyone's misery when DSL showed up. And now, finally, after fifty years of pissing about, fiber is finally being pulled to the premises.

If you really need ongoing ISDN support, you can pull the source code from an old Git commit and update it. But I feel quite comfortable in opining: ISDN support will not be missed.

Back in the day lots of people did. Because there was no built in browser to use before IE came out. And pirating it would require getting a cd from someone else, and cd burners weren't a thing yet. Your options were use AOL with whatever they had built in on their cds, or use Netscape which you'd need to buy.

If tickets were an auction, the problem would instantly solve itself. You could even still have a secondary market for last minute buyers. And the extra revenue would go to the venue/artists, rather than a random scalper.... if those even exist anymore. I expect it's more likely Ticketmaster themselves selling them as resell at a 3x markup.

I have been to all of the QC Snapdragon briefs, know the engineers personally, and have written about the shitshow on SemiAccurate.com extensively, basically I know what is going on. QC doesn't understand what they are doing and why, and there is ZERO internal impetus to change from the people on top. They do nearly nothing on software enablement because, "That is Microsoft's job". Drivers are intentionally locked down and encrypted to block Linux, and x86 compatibility is BETTER in hardware than the Mac Mx line (Same people who did the M1 and M2 did the X1 and X2, and they all just bailed on QC) but the software is.... oh look outside, there is a sky.

TLDR: No chance in hell there will be a fix.

                    -Charlie

Those cards would be worth far more than the data at the moment.

...My installation of minidlna still works fine, is Free Software, and doesn't phone home or exfiltrate my metadata.