ploxiln (u/ploxiln) - Readit News

ploxiln commented on Deprecations via warnings don't work for Python libraries sethmlarson.dev/deprecati... · Posted by u/scolby33

theamk · 9 days ago

Deprecations via warnings don't reliably work anywhere, in general.

If you are a good developer, you'll have extensive unit test coverage and CI. You never see the unit test output (unless they fail) - so warnings go unnoticed.

If you are a bad developer, you have no idea what you are doing and you ignore all warnings unless program crashes.

ploxiln · 7 days ago

When I update python version, python packages, container image, etc for a service, I take a quick look at CI output, in addition to the all the other checks I do (like a couple basic real-world-usage end-to-end usage tests), to "smoke test" whether something not caught by outright CI failure caused some subtle problem.

So, I do often see deprecation warnings in CI output, and fix them. Am I a bad developer?

I think the mistake here is making some warnings default-hidden. The developer who cares about the user running their the app in a terminal can add a line of code to suppress them for users, and be more aware of this whole topic as a result (and have it more evident near the entrypoint of the program, for later devs to see also).

I think that making warnings error or hidden removes warnings as a useful tool.

But this is an old argument: Who should see Python warnings? (2017) https://lwn.net/Articles/740804/

ploxiln commented on Israeli-founded app preloaded on Samsung phones is attracting controversy sammobile.com/news/israel... · Posted by u/croes

xethos · a month ago

I agree, and that's the exact point I would make. The problem though, is I want a small phone with a headphone jack (and a physical keyboard, but that's orthogonal to the point).

Many OEMs sell their flagship as a shiny glass slab with only BT or USB-C for audio, and ship 3.5mm jacks and other "antiquated niceties" like a uSD card reader, on their lower-end models.

It's difficult to square the circle of "I want these specific features, but on a phone that's not working against me (any more than modern phones already do)"

ploxiln · a month ago

The "Sony Xperia 5 V" (I have the previous "Sony Xperia 5 IV") has a headphone jack, takes a uSD card, and is somewhat compact. (And no silly camera cutout in the screen, it's in a reasonably small bezel.)

EDIT: also see the Xperia 10 VII for a phone that isn't 2 years old (I haven't been keeping up, I buy phones to use for 4+ years)

ploxiln commented on A new chapter begins for EV batteries with the expiry of key LFP patents shoosmiths.com/insights/a... · Posted by u/toomuchtodo

dust42 · a month ago

BloombergNEF has over the years proven to have pretty solid forecasts. The current one about NEVs [1] has a few interesting points. Adoption of EVs is slowing down in the US due to policy changes but going to explode in countries like Vietnam because they are cheeper to buy an run. It is not BMWs and Mercs but Chinese brands.

In Europe and the US the Chinese EVs are kept outside with the help of tariffs but that is just closing the eyes to avoid facing the inevitability. Battery technology, production and raw materials is all China.

Last not least Europe is driving up KWh costs by an ideologically driven push for renewables which also doesn't help.

[1] https://about.bnef.com/insights/clean-transport/electric-veh...

ploxiln · a month ago

For many years (20+?) Vietnam has had huge import tariffs on US/German/etc cars. It varies by origin country and engine displacement, but it's around 75% to 175%. Some trade agreements with other Asian countries result in much more reasonable tariffs for Asian brands, but some rich Vietnamese people have bought BMW or Merc with 150%+ tariff/tax. (I found it a bit mind-blowing.) So, it's pretty obvious why Asian made EVs are expected to "explode" in popularity over there. (I'm pretty sure the trend is already well underway, I know a retired guy there who replaced a Merc with a hybrid Mitsubishi (?) last year.)

ploxiln commented on Supply chain attacks are exploiting our assumptions blog.trailofbits.com/2025... · Posted by u/crescit_eundo

bluGill · a month ago

The supply chain attack always existed. C because it didn't have a package manager made it slightly harder in that a dependency wouldn't be automatically updated, while Rust can do that. However this is very slight - in linux many people use libraries from a package manager which gets updated when there is a new release - it wouldn't be hard to get a bad update into a package (xz did that).

If you have packages that don't come from a package manager - windows install, phone installs, snap, docker, flatpack, and likely more you have a different risk - a library may not have been updated and so you are vulnerable to a known flaw.

There is no good/easy answer to supply chain risk. It is slightly different on Rust because you can take the latest if you want (but there is plenty of ability to stay with an older release if you want), but this it doesn't move the needle on overall risk.

ploxiln · a month ago

> it wouldn't be hard to get a bad update into a package (xz did that)

I'd actually call that quite difficult. In the case of xz it was a quite high-effort "long con" the likes of which we've never seen before, and it didn't quite succeed in the end (it was caught before rolling out to stable distros and did not successfully exploit any target). One huge close call, but so far zero successes, over almost 30 years now.

But typo-squatting and hijacked packages in NPM and PyPI, we've seen that 100s of times, many times successfully attacking developers at important software companies or just siphoning cryptocurrency.

ploxiln commented on End of Japanese community support.mozilla.org/en-US... · Posted by u/phantomathkg

kstenerud · a month ago

I know that everyone has already given their opinions about what kinds of people are involved and their motivations, but this is really about two fallible humans, one listing grievances and another asking to open a communication channel.

That's it.

Anything else you read into this is going to be fraught with your own coloring based on a hundred words written in text (a notoriously difficult medium to establish emotional communication over).

Regardless of how nice or not-nice the text may sound to the various cultures that have weighed in so far, the right thing to do is talk voice/video and hash out what the problems are, and work together to come up with a solution that will satisfy everyone.

That's what communication is about.

ploxiln · a month ago

The grievances were rather detailed and concise. The communication channel is right there already. The relevant Mozilla employee should have responded with a detailed and concise explanation, of either why the translator is wrong, or why mozilla messed up and how they will fix it. They should post for public and historical record.

But instead, they asked to "hop on a call" which really grinds my gears, I've been asked this a few times in similar situations before. I guess there's two people here: the engineers who really hate this tactic, and the managers who - well, this is what they do. Of course it's the most reasonable thing?

ploxiln commented on Internet Archive's legal fights are over, but its founder mourns what was lost arstechnica.com/tech-poli... · Posted by u/thinkcontext

Aeolun · a month ago

And then the IA becomes the same thing it’s fighting against. The people in the wrong here are these massive corporations fighting over scraps, not the IA.

ploxiln · a month ago

No it doesn't. It's extremely valuable with the scope it already has. These massive corporations do not operate the Wayback Machine nor the various (less controversial) public archives that IA hosts, and makes available at no cost, no login-wall, no cloudflare-infinite-captchas, etc.

ploxiln commented on Introducing architecture variants discourse.ubuntu.com/t/in... · Posted by u/jnsgruk

ninkendo · 2 months ago

> show that most packages show a slight (around 1%) performance improvement

This takes me back to arguing with Gentoo users 20 years ago who insisted that compiling everything from source for their machine made everything faster.

The consensus at the time was basically "theoretically, it's possible, but in practice, gcc isn't really doing much with the extra instructions anyway".

Then there's stuff like glibc which has custom assembly versions of things like memcpy/etc, and selects from them at startup. I'm not really sure if that was common 20 years ago but it is now.

It's cool that after 20 years we can finally start using the newer instructions in binary packages, but it definitely seems to not matter all that much, still.

ploxiln · 2 months ago

FWIW the cool thing about gentoo was the "use-flags", to enable/disable compile-time features in various packages. Build some apps with GTK or with just the command-line version, with libao or pulse-audio, etc. Nowadays some distro packages have "optional dependencies" and variants like foobar-cli and foobar-gui, but not nearly as comprehensive as Gentoo of course. Learning about some minor custom CFLAGS was just part of the fun (and yeah some "funroll-loops" site was making fun of "gentoo ricers" way back then already).

I used Gentoo a lot, jeez, between 20 and 15 years ago, and the install guide guiding me through partitioning disks, formatting disks, unpacking tarballs, editing config files, and running grub-install etc, was so incredibly valuable to me that I have trouble expressing it.

ploxiln commented on Kafka is Fast – I'll use Postgres topicpartition.io/blog/po... · Posted by u/enether

MrDarcy · 2 months ago

Is the mapping of use cases to software functionality not a power law distribution? Meaning there are a few use cases that have a disproportionate affect on the desired outcome if provided by the software?

ploxiln · 2 months ago

It probably applies better to users of software, e.g. 80% of users use just 20% of the features in Postgres (or MS Word). This probably only works, roughly, when the number of features is very large and the number of users is very large, and it's still very very rough, kinda obviously. (It could well be 80% / 5% in these cases!)

For very simple software, most users use all the features. For very specialized software, there's very few users, and they use all the features.

> The claim is that it handles 80%+ of their use cases with 20% of the development effort. (Pareto Principle)

This is different units entirely! Development effort? How is this the Pareto Principle at all?

(To the GP's point, would "ls" cover 80% of the use cases of "cut" with 20% of the effort? Or would MS Word cover 80% of the use cases of postgresql with 20% of the effort? Because the scientific Pareto Principle tells us so?)

Hey, it's really not important, just an idea that with Postgres you can cover a lot of use cases with a lot less effort than configuring/maintaining a Kafka cluster on the side, and that's plausible. It's just that some "nerds" who care about being "technically correct" object to using the term "pareto principle" to sound scientific here, that bit is just nonsense.

ploxiln commented on Uv is the best thing to happen to the Python ecosystem in a decade emily.space/posts/251023-... · Posted by u/todsacerdoti

bruckie · 2 months ago

From "So how does Astral plan to make money? " (https://news.ycombinator.com/item?id=44358216):

"What I want to do is build software that vertically integrates with our open source tools, and sell that software to companies that are already using Ruff, uv, etc. Alternatives to things that companies already pay for today. An example of what this might look like [...] would be something like an enterprise-focused private package registry."

There's also this interview with Charlie Marsh (Astral founder): https://timclicks.dev/podcast/supercharging-python-tooling-a... (specifically the "Building a commerical company with venture capital " section)

ploxiln · 2 months ago

hmm how well did that work for Docker ...

ploxiln commented on Rust cross-platform GPUI components github.com/longbridge/gpu... · Posted by u/xvilka

iknowstuff · 2 months ago

No advantage to it. Worse quality code to gain what? A smaller number hiding ultimately the same amount of code? Also, since the unit of compilation is a crate, fewer opportunities for concurrent compiling.

ploxiln · 2 months ago

A multitude of tiny dependencies has a multitude of solo maintainers, who eventually walk away, or sometimes get compromised.

A few big dependencies each have a team and a reputation that has earned trust and established release process and standards. If there's a serious problem in a small part of a big dependency, there are a few trusted maintainers of the big dependency who can be reached and can resolve it.

The theory of small dependencies was a good theory, 10 years ago when js devs using NPM started the trend of making them "as small as possible". But it really seems like the emergent pattern is the opposite of what is claimed. These JS and Rust projects end up taking longer to build and resulting in bigger outputs. Instead of a couple of "huge" 200KB dependencies, you end up with _thousands_ of 1KB dependencies including different versions and alternative implementations, you end up with megabytes of "accidental" code you don't really need.

And we can reason about why. In an ecosystem where something has 1 to 3 large deps, well sometimes a dependency pulls in another sub-dependency with code you don't need. But in an ecosystem where something has 10 to 100 deps, this still happens, but 50x more overall. It's a exponential trend: you have 3 big deps that each have 2 big deps that each have 1 big dep, vs you have 20 small deps that each have 15 small deps that each have 10 small deps.