ntoshev

Is vast.ai reliable for production inference where downtime is important?

You can modify this one to do that - or write your own using the same approach:

https://github.com/danielgross/localpilot

Copilot doesn't continuously update your code when you make changes.

Musk is an engineer. Engineers want impact, not power.

My reading is the server with zsync can be any http server, client is zsync. Rsync on the other hand needs to use rsync on the server, and it scales badly because it does most work on the server.

Came here to find the thread discussing this. You stated what I'd think is the conventional wisdom and I expected this to be the top thread.

However, this thinking comes at the cost of UX (or Developer eXperience). Much more mundane instance of the same thinking is hiding elements of the UI you are not allowed to use. This often gets me thinking - is there a way to do this that I'm not allowed to see, or is it just that I can't find the function in the UI?

A solution for the DX issue is logging the real error somewhere only accessible for an admin. Has this been implemeted anywhere in the wild? For UIs, just be honest and show the menu items disabled.

Partisia | Aarhus, Denmark or REMOTE | https://www.partisiablockchain.com

Do you want to build the next generation internet platform?

Blockchains with smart contract support (like Ethereum) allow for arbitrary computations with guaranteed integrity. However, computations are public, which is often a major limitation. Partisia is making a blockchain where computations can also be confidential, even to the nodes that are running it. It is done with a blockchain based secure multiparty computation (MPC) orchestration platform. MPC is an extension of ZK proofs, giving the possibility to perform arbitrary privacy-preserving computations.

We need engineers to work on a new programming language for writing smart contracts which allows distinguishing public state from private state. Executing computations in MPC requires specialized optimization and reordering of the computation graph - which needs to be integrated into the execution environment of the language. Expertise in compilers, optimization, graph theory, distributed systems or cryptography is helpful.

Apply here: https://partisia.com/career/programming-language-expert-for-...

We are also looking for people to build the governance layer of the blockchain, i.e. the operating system for users of the platform. This work will be part software part cryptographic engineering. Understanding of game theory and finance is helpful.

Apply here: https://partisia.com/career/software-developer-governance/

Great resource, I'd missed a few goodies. https://javascript.info is similarly good in teaching modern Javascript.

I wish there was such a resource for modern C++ though. I learned and used C++ in the 90s and early 2000s, and apparently the language has progressed a lot meanwhile. People say idiomatic modern C++ (C++14/17/20) can be pleasant and metaprogramming capabilities are really powerful.

Network latency is not accounted for: they use AWS lambda calling DynamoDB / Redis in the same data center; Fauna endpoint is somewhere else.

Curious what Firebase latency would be in comparison, when called from the same GCP data center or AWS.

Abstraction discovery is a hard problem in general. Good names help, but there's probably more we can do. Tooling finding a common pattern that the abstraction eliminates, perhaps?

You should be able to take your personal webpage off archive.org if you don't want it there. I think the mechanism is via the current robots.txt file.

It's no really about experience but rather about the ability to reason from first principles. Lots of developers with experience don't even attempt doing something because the structure of the problem demands it; they would only do something if they've seen a similar approach before.

Ansible is pretty declarative actually, it won't repeat tasks that are already performed if it can figure it out.

Could you share the source for this? It's very useful for understanding the situation.

AFAIK there exist cryptographic protocols that can authenticate you without revealing the password to the server. They aren't standard though.

Lambda is not suitable for certain workloads. It's impossible to know what is the problem in this particular case from the details provided by the author. I can give some common examples where Lambda would NOT work well:

* if the code you run has heavy initialization phase that could be amortized across multiple runs. Lambda is not a god fit because you'd do initialization for every request. Cold start latency compounds with code initialization to make the problem worse

* if the function workload involves lots of waiting for network I/O (REST APIs, lots of database calls, web crawling). In this case you'll be paying for each lambda function to wait for the network, while if you run the same workload on a single machine it will be cheaper because you can wait for many requests in parallel in different threads without consuming much resources.

Having mechanical sympathy for your workload does help.

> The kind of architectural surgery required to address this is correctly seen as something you can't upstream to the main open source code base.

Why is this?

Still feels like it could be an OTA update in a Tesla. The "car world" needs to change and change has begun.

It's certainly task-dependent at least to some extent. If the task at hand is to fix a zillion spelling errors in the UI, there is certainly no 10x variance in programmer's ability (there might be a big variance in motivation though, and individual performance is a product of motivation and ability).

> For every set of "unique" insights, there is almost always many sets of unrelated data sources that can be analytically combined to deliver the same insights. In the slightly seedy underworld of data model brokers, I've seen some very impressive examples of this.

If you could share a couple of examples it would help a lot to get your point across.

FWIW, I agree with the thesis that data intensive computation could be one or two orders of magnitude more efficient than it currently is, with sufficient engineering. Probably Cassandra vs ScyllaDB is a good public example, and ScyllaDB is likely not close to the theoretical optimum at all. But I'm not sure about deriving data from alternative sources. How do you derive movement data for everyone with an Android phone if you're not Google?

Definitely one of the most efficient ways. All the literature about expert performance stress on deliberate practice.

Google offers their most recent infrastructure as a service in GCP, e.g. Cloud Dataflow, and it hasn't exactly taken the world by storm. Industry standards matter, even if they are inferior implementations; the differential is just not that big.

What a useless article. Reading it, you would think Azure is somehow leading on AWS, when market share is 33% AWS vs 13% Azure. This is never mentioned among the buzzwords.

I'd like to be able to load log files in a database and have it take the same space as compressed log file size, not the uncompressed size (which can easily be 20x more). I guess this requires database built on compact data structures or something similar, but surely simple support for dictionary compression for database text fields would help? Text fields are small chunks of text of the same type, so they should be amenable to good compression with the same dictionary. I've searched around and found some support in RocksDB, but that's pretty much it.

Most compression libraries offer dictionary support, although it's somewhat obscure. For example, there is no method in zlib to actually create your dictionary. Bindings and higher level libraries often ignore the dictionary support.

Apparently the way LMDB does I/O is exercising slower (more complex?) code paths in the virtualization implementation code compared to LevelDB, and virtualization overhead is significant in these benchmarks (actually slows down execution several times).

LMDB does mmap while LevelDB does plain file I/O.

Could EFF disclose statistics on the NSLs they are fighting but can't talk about individually? E.g. can they say "We are currently fighting 50 NSLs with gag orders?"

If not, that's a good pressure point for a change in current legislation. I can't possibly imagine a scenario where disclosing the number of NSL would be a threat to national security.

My understanding is that different user roles would see different schemas depending on what they are allowed to see. This should definitely reduce the amount of code that needs to be written. I haven't actually implemented such an API though, so I may be wrong.

If you want you can run it in production, too (this would give you a warning, won't prevent race conditions, but there is almost no performance penalty). The point was this is very different from a mutex.

This only runs in the debug version of the code. I hope your mutexes run in production, too.