logophobia

Sounds more like a political issue this. Can't buy your way out of that.

What is wrong with the following solution?

Any trait implementations where the type and trait are not local are:

* Private, and cannot be exported from a crate

* The local trait implementation always overrides any external implementation

That would solve part of the problem right? Only crate libraries that want to offer trait implementations for external traits/types are not possible, but that might be a good thing.

The solution proposed by the author with implicits is quite complex, I can see why it wasn't chosen.

Because it means that a business (as in, facebook) knows too much about you. It's extremely invasive privacy-wise. Things that could happen:

* Micro-targeting for political advertisements (pretty bad for democracy)

* Dynamic pricing based on demographics (you can afford it, so you pay more)

* Insurance knowing too much about you (rejections based on your health, ensuring parts of the population won't be able to get good insurance)

* And just the fact that too much information being public can be harmful (blackmail, scams, etc)

* etc..

If your dependency has a security update, how are you going to get that if you copy-paste the code? The thing these dependency managers do well is that they notify you about these types of issues.

.. That said, people need to be very careful about what they add as dependency. Having 1000+ transitive dependencies is just asking for security issues.

I once, for a short period, maintained web-application that had three different frontend frameworks (angular 1, angular 2, and one other I don't quite remember), and four different javascript builds that had to be run to build the application. Apparently management prioritized the giving demos to investors, and changes to different frameworks were aborted halfway through.

It was completely impossible to work with. Each week the build failed for new random reasons. I hardly dared touch the thing.

This "pattern" is really a failure from multiple parties:

* Managing software engineers is an art, and you really need to understand what is happening to succeed. Only prioritizing short-term goals just ensures you're going to fail in the long-term. Make sure you understand technical debt. The speed of work in bad code-bases versus good code-bases can be orders of magnitude in difference.

* Software engineers really need to use branches properly. Work that is halfway done should not be in the main branch. Consistency and simplicity is king here. Maintaining an old and new version of software for a while can be a pain, but it's much better than maintaining a halfway converted application. Pressure from management is no reason to release stuff halfway done. And if you need to demo, release a specific branch.

Nowadays I don't even ask to do necessary maintenance. It's just part of the job. Always stick to the boyscout rule (leave things in a better state then you found it). Make your code-bases cleaner incrementally, and eventually you'll be in a much better state.

Or have a lower melting point, making it more practical to use some sort of heat-resistant armoring? Might be pretty difficult to make something that both reflects light and is heat-resistant, no mirror reflects everything.

An alternative which I've used with some succes are structured state space models: https://srush.github.io/annotated-s4/. A very different approach that works well for quite a few types of problems.

The typical setup is very simple:

* Take the previous model checkpoint, retrain/finetune it on a window with new data. You typically don't want to retrain everything from scratch, saves time and money. For large models you need specialized GPUs to train them, so typically the training happens separately. * Check the model statistics in depth. We look at way more statistics then just the loss function. * Check actual examples of the model in action * Check the data quality. If the data is bad, then you're just amplifying human mistakes with a model. * Push it to production, monitor the result

MLOps practice differs from to team to team, this checklist isn't universal, just one possible approach. Everyone does things a little differently.

I still think of how humans work. We don't get retrained from time to time to improve, we learn continually as we gain experience. It should be doable in at least some cases, like classification where it's easy to tell if a label is right or wrong.

For some models, like fraud, correctness is important. Those models need a lot of babysitting. For humans, think about how the average facebooker reacts to misinformation, you don't want that to happen with your model.

Other models are ok with more passive monitoring, things like recommendation systems.

Continuous online training can be done. Maybe take a look at reinforcement learning? It's not widely applied, has some limitations, but also some interesting applications. These types of things might become more common in the future.

That's a pretty standard part of MLOps. I have a fraud model in production, it's being incrementally retrained each week, on a sliding window of data for the last x-months.

You can do it "online", which works for some models, but for most need monitoring to make sure they don't go off the rails.

I've applied the S4 operator to successfully do long-length video classification. It's massively more efficient than a similarly scaled transformer, but it doesn't train as well. Still, even with S4 I got some impressive results, looking forward to more.

Reminds me of the ideas behind google's multi-axis transformer: https://arxiv.org/abs/2204.01697

Both using a hierarchical transformer, adapting the transformer network architecture to vision tasks more efficiently.

I stopped using nordvpn once they started disabling features when I disabled autorenewal: https://old.reddit.com/r/assholedesign/comments/ldf9g9/nordv...

A VPN provider really needs a lot of trust, easy to lose that.

Tried to reset my password, whole site is offline right now, probably too many people resetting their passwords.

Tried a quiz. I'd be nice if there was more explanation about the things I missed. I get a question about naming ingredients. I get some wrong. Afterwards it might be nice to get an explanation about the missed items so I don't have to google myself. Even an in-app link to wikipedia would be enough. I also suspect that most things I got wrong were because of language differences, so translations might be nice as well.

Consider using background subtraction for this: https://docs.opencv.org/4.x/d1/dc5/tutorial_background_subtr...

Will make things a little more robust (and overengineered!).

Huh, clever use of btrfs volumes, it does make it a little dependent on the filesystem though. Quite informative overall, probably implements only a fraction of docker, but it does do most of what you'd typically need.

I didn't mean legal responsibility here (perhaps the example was somewhat poorly chosen), but surely there's some level of responsibility here? Bugs happen, security issues happen, facts of life, but actively rejecting security patches is another level of irresponsibility.

It was advertised as a production-ready web-framework, and it was very popular. When do people get to complain? "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.". Web-frameworks are cornerstones for security, and if you write one, advertise one, you need to care about security. Features, code-style, ad-hoc PRs, bug-fixes: little responsibility there, but security is something that can hurt a lot of people if done wrong. The use-after-free bug this was about could've been exploited in the right circumstances.

If I build a playground for free and it gets popular in my neighbourhood, and then collapses on some poor kid, I'm still responsible, even if I did it for free.

The way it was handled was definitely NOT productive though, the guy didn't deserve the flames.

However, that doesn't mean there wasn't a problem. There was a ton of negativity around "unsafe" when the author first released the code, and it has kind of become a meme at this point. If a project consistently uses code in an unsafe way, is it really worth spending your time vetting it for your production use case? There are plenty of web severs out there, pick one that aligns with your goals.

Should people wait until credit-card data or PII is leaked due to security vulnerabilities? The problem with security is that it impacts more than just the programmers using the framework, it impacts everyone. Does the author deserve the nastiness? No. Do security issues need to be reported, and if not fixed, called out? Yes, for big and advertised projects issues like that need to be reported. If not, there will be users that would naively expect the web-framework they're using to be somewhat secure.

The framework had a professional looking website advertising the project, it had good documentation, a user-friendly API. It advertised a actix open-source community. Had over a million downloads. I would say that expecting actix to be run like a somewhat professional project is not a strange assumption.

The way it was called out was pretty terrible though, and I doubt anyone is happy with what happened.

It's not coding style, it's refusing to investigate use-after-free vulnerabilities in code because it's "boring". Noone should care if a maintainer uses tabs or spaces, or has weird variable naming, but if "coding-style" leads to security issues (due to hand-rolling unsafe memory-primitives), then it is an actual issue, especially if it's for a popular web-framework.

Don't like it, don't use it doesn't really apply to security vulnerabilities in such major packages.

Flaming and personal attacks are not the solution to this stuff, but this drama feels somewhat self-inflicted.

He probably means legalizing prostitution, which would (hopefully) reduce trafficking if the demand can be met legally.

I haven't received an e-mail, I've got multiple docker-hub accounts.

Isn't that one of the reasons rust compiles with JEMalloc? Fragmentation avoidance is one of its main features. Otherwise, using arenas or other strategies work very well for avoiding fragmentation. I generally haven't run into issues, mainly because rust allows me to use a lot less memory which helps.

Rust code also has less dynamic memory allocation in general. You allocate for dynamically sized datastructures and long-lived data, but not like c# or java where each non-value class type is allocated on the heap (unless the compiler is smart enough to use escape analysis).

ETL, that way you can also ensure your data gets put in a format that'd make it easy to report on.

Granted, it's not quite as quick as this, and not suited for "one-off" reporting, but it's a lot more flexible. Put things in a nice star schema and you have a good way to do analytics on your data.

Gotta say, stuff like this is getting a bit more common. Last month while I was evaluating choices for an application gateway I saw that:

* Ngnix has an enterprise version

* Kong has an enterprise version

* HAProxy has an enterprise version

Now redis as well, even if the commons license isn't quite as bad, it's a step back. It's understandable, but all a bit disappointing.

It was proven in 2002, has a formal definition, so I'm going with calling it a theorem. Maybe this'll help: https://mwhittaker.github.io/blog/an_illustrated_proof_of_th... ?

He's probably refering to a combination of features that "nosql" databases have.

* Schema-on-read: Makes it easier to ingest large amounts of data, and then do ad-hoc exploration. The schema is only determined when reading the data, which is a bit easier for one-off data exploration, you determine how to interpret the data when actually using it. Not appropriate for production systems though. For example, a customer gives you a few TBs of data, you dump it on hadoop, and query it with spark. It would slow you down if you first have to convert it to a relational schema. Again, only good for one-off stuff.

* Most SQL databases have column limits, so if you have a very large amount of features, I'd imagine you'd run into these limits.

* Scalability. Feature engineering is very parallelizable, most normal SQL databases (excluding stuff like cassandra) aren't trivial to scale.

I think I misunderstood that yes.

https://storage.googleapis.com/pub-tools-public-publication-....

TLDR: It's technically CP, but google claims partitions are so rare people can assume it's CA as well (99.999% available).

I assumed TrueTime bypassed the CAP theorem, but apparently that's marketing bs. It's to ensure something called external consistency, which is important if you want to take consistent snapshots over a distributed system.

I've met developers like that.

Although honestly, sql is more than 40 years old and can be really nasty. Stored procedures, each database has a different dialect, nullability comparisons, CTEs. It's very different from any other programming language. It's not that hard to imagine people finding it hard to learn, especially front-end web developers who'd rather not touch the backend. If people don't know how indexes work, then it'll perform really badly as well, which would make databases like mongodb all the more attractive.

Not all developers are formally schooled, a lot of people don't know what a relational database model is.

I've seen people:

* Iterate over entire tables to get to a small number of records

* Not using joins, having the ORM "magically" handle everything (lazily getting non-joined values in separate queries, resulting in thousands of queries)

* Denormalize everything, and then wonder why things are inconsistent and hard to query

I've seen some of those applications. It might be easier & faster to start with a schema-less json database, but I saw some serious maintenance issues with applications like that:

* Using the stored data outside the use cases imagined by the original developer is harder than it should be. (Oh you want a customer dashboard with this and this data correlated, ..)

* "Migrations" can be rather error-prone if developers don't pay attention. (It was stored as a string first, and now it's an integer, now how do we query that). Just because there's no database schema, doesn't mean there's no schema.

* It's hard to see what's actually in a json table/collection. You'd need to browse the code, see how it's used, and then browse through the available data.