maksimum
I think in most cases you have to trust some group of parties. As an individual you likely don't have enough time and expertise to fully validate everything that runs on your hardware.
Do you trust the OSS community, hardware vendors, OS vendors like IBM, Apple, M$, do you trust third party vendors like Crowdstrike?
For me, I prefer to minimize the number of parties I have to trust, and my trust is based on historical track record. I don't mind paying and giving up functionality.
Using your definition of class X
%timeit x.w()
313 ns ± 18.3 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
class X:
__slots__ = ('a')
def w(z):
a = z.a
return a+a+a+a+a
%timeit x.w()
271 ns ± 7.13 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
That's a condition for all TDD.
> I know there's testing frameworks, although it seems more of an eclectic mess than Java
If you look at the test suites for popular libraries like numpy, django, airflow it's mostly `pytest`, `unittest` (part of the standard library), and `nose`.
> where testing and mocking is just a little harder to do...
Mocking is actually pretty easy to do in python using pytest.monkeypatch or unittest.mock. Compared to mocking in a strongly typed language like C++ (and I assume Java) if an object you're mocking implements a particular interface, you would only have to mock out the parts that get exercied by the codepath in the tests you care about.
I think you could look at the battle/war from a different perspectives, and come up with different conclusions.
In the mainstream (whatever that is?) it appears that convenience wins. And hardware/software vendors seem to make the assumption that customers won't complain if their data is harvested. I think that's where you're coming from?
On the (privacy) enthusiast things, the horizon looks much better. We've got great software that makes self-hosting easier: FreeNAS, Nextcloud, Docker, Plex, NixOS, etc. We have more choice in phones: we can still use "dumbphones", or use open source operating systems, or choose manufacturers with better privacy track records. I'm not familiar with consumer electronics as much, but buying low end/dumb devices (TVs, appliances) is still viable. And the open source home automation movement keeps getting traction with hardware and software.
According to [1] using 3 letters you'd need at least 72 commits to have at least 50% chance to observe a clash. Using 6 letters you'd need at least 3977 commits, lol.
[1] https://en.wikipedia.org/wiki/Birthday_problem#The_generaliz...
Do you know of git GUIs that explicitly maintain a bijection between the GUI and the underlying command history? It'd be cool to use the GUI and see the command history, or use the CLI and see updates in the GUI.
Based on my experience Lyft and Uber charge different prices to different customers with identical trips. I've tested this by asking friends with who I'm about to share a ride with to request the same trip as me, and compare prices. We've observed differences of 10-20%.
> Knowing what your service is worth to customers so you can extract a greater fraction of this is pricing 101.
Where this becomes problematic is in the age of big data. When a company can build an accurate profile of me, they can extract maximum prices from me. We need laws that mandate what definition of "profile" is allowed to be used for pricing.
I'm not sure why we accept price discrimination at the individual level for airlines and Lyft/Uber. I'm pretty sure people would be outraged if Amazon started price discriminating based on your purchase history.
It's weird to me that this sort of price discrimination is legal.
E.g. given this information, my incentive as a rider is to never tip (so that their algorithm doesn't identify me as "willing to pay" more). Maybe I could also make a new Lyft account every time I need a ride?
What's the situation where your application needs to go first in the Dockerfile, and then you need to put a bunch of stuff that doesn't depend on your application?
These days, most productions environments are effectively isolated containers. If your production environment is a container, you probably should develop in a container as well. In that case you don't need much tooling for isolating an application's dependencies from other applications.
The tooling that you need is to build a python application, which means (1) get the dependencies (2) copy over some source code (or invoke the C-compiler if build a C<->Python extension) (3) run tests. Python's builtin setuptools does that fine. It didn't strike me as amazingly simple, but it's not amazingly complex either. pip is essentially a convenience wrapper for setuptools, i.e. pip is to setuptools as apt is to dpkg.
Basically, I believe that because of docker isolation is a irrelevant criterion by which to judge a language/ecosystem.
I imagine if you're deploying docker, you probably should be developing in docker (e.g. using PyCharm's remote interpreter/docker interpreter integration).
Do you think private browsing sessions are also unclear/have unintuitive UX? It seems like firefox containers are just private browsing sessions that you can close and re-open.
They publicly describe a habit that they claim is useful. To me that implies that they're suggesting others invest time into the habit.
But I've never been compelled by the arguments. I haven't seen someone try to make (even qualitatively) refutable claims. If you don't make refutable claims, how can I experiment in order to see whether the habit makes sense for me?
https://en.wikipedia.org/wiki/Diablo_II
https://en.wikipedia.org/wiki/StarCraft:_Brood_War
This is mainly relevant if your data is used for training.
It seems like you'd want to use a log-based system like kafka to manage versioning and state in this case. I imagine you could:
1. Store incoming training data in a "raw data" topic.
2. A model trainer consumes incoming training data, updates a model's state, and at a pre-determined period writes the model's state as of a given offset in the "raw data" topic in a "model state checkpoint" topic.
3. Then you probably have some "regression testing" workflow that reads from the "model state checkpoint" topic and upon success writes to a "latest best model" topic.
4. Workers that use the model in production read from the "latest best model" topic and update their state upon a change.
I imagine you could add constraints about "model" continuity or gradual release to production that would make the process more complex, but I feel like fundamentally kafka solves a lot of the distributed systems problems.
I feel that mounting a NFS partition is a similar break of contract. I.e. you could see the same image behave differently depending on what's in the NFS partition. I feel like to get data in a "reproducible" way you need to pull it from a data versioning system. I think there's different ways to implement data versioning with their own trade-offs. NFS and S3, among others, could be used to implement data versioning.
I agree with you that in theory an NFS is more performant because it allows you to load lazily.
The article does a good job of explaining why YouTube and Facebook don't currently do a good job of currating content, or whether that should even be their responsibility. It's not about machine learning, it's about price incentives.
Identifying themes in video is harder than natural language. But fundamentally it requires the same kind of ML tools as natural language, which these companies have already mastered. I think the bigger issue is that Facebook doesn't have a business purpose for understanding video as compelling as it has for understanding natural language. They also don't have a business purpose for building scalable content censoring workflows since there's no serious regulation.