pdeva1

This is closer to 5.1 mini it seems and tied to Pro account. GLM 4.7 is available on-demand on Cerebras today [1] and performs better and cheaper... [1] https://www.cerebras.ai/blog/glm-4-7

AWS has the Google TrueTime equivalent precision clock available for public use[1] which makes this problem much easier to solve now. Auora DSQL uses it. Even third party db's like YugabyteDb make use of it.

[1] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time...

is Composer a fine tune of an existing open source base model?

this algorithm is flawed. i created a test which can read failed write https://gist.github.com/pdeva/58854fa644d074cf07aa0ecca9a465...

2. ok. so can i rebuild a cluster with just state in s3? eg: i create a cluster with local disks and s3 backing. entire cluster gets deleted. if i recreate cluster and point to same s3 bucket, will it restore its state?

1. can this be used without clickhouse as just a zookeeper replacement? 2. am i correct in that its using s3 as disk? so can it be run as stateless pods in k8s? 3. if it uses s3, how are latency and costs of PUTs affected? does every write result in a PUT call to s3?

1. what payload size and flush interval is that latency measured against?

1. dont producers now have much higher latency since they have to wait for writes to s3.

2. if the '5-10x cheaper' is mostly due to cross AZ savings, isnt that offered by AWS MSK offering too?

one of the reasons Bazel needs BUILD files with explicit inputs /outputs defined per file is to do fine grained incremental builds and test runs. so if i change say foo.c, i only need to recompile foo.obj and run ‘foo-tests’. Moon seems to take globs as input. Thus modifying even a single file inside ‘src’ dir will trigger rebuild/retest of the entire ‘project’

actually that timestamp is deceptive since the frame it opens at is the real jensen. this timestamp shows the cgi jensen and its very obvious due to the distance and animation that it is indeed cgi. https://youtu.be/eAn_oiZwUXA?t=3761

note that this is only for 14 seconds of the video, when it is very obvious in the video that it is indeed a cgi figure.

I do think Facebook has the correct direction on this.

how do you know which steps to skip or rerun each run. in your react example, how do you know when to reinstall yarn to latest version and when to skip. https://layerci.com/docs/examples/react

one thing that doesn't get talked about RDS is that network cost for replication of data for RDS multi A-Z deployments is free. Depending on how much you write to RDS, this cost can dominate cpu/memory costs on non-RDS installations.

what do you mean by ‘extra memory overhead’

on the comparison with Consolas section, it says consolas is wider than JBMono, and JBMono is taller. However, the lines of code in the example run longer in the JBMono version than Consolas. Why is that? is the comparison flawed?

how does insurance work for the rental period? prices seem similar to hertz and enterprise, why would i chose it above those?

thanks for clarifying. appreciate the detailed answer.

correct me if i am wrong here:

1. burger case, i do: count = count-1 if both txs see count=1, we get count=0 at the end.

2. i didnt say banking per se. can involve a simple billing system of a startup. or any critical data where you need to ensure you are reading accurate, uptodate values. maybe a leaderboard.

>You'll likely see a current value most of the time

'most' is not a guarantee :) either the system is designed with seeing uptodate values or not. and if 'some' of the time the value is stale, you have to program with low consistency in mind.

the marketing on yugabyte's page makes it seems it can replace db's like cassandra and give you a consistent view of your data. but if one is seeing stale values, you are back to coding like data is non-consistent

>you just might not observe the state of the counter as it was a few milliseconds

did you mean 'might observe' instead of 'might not'? stale read would result in the older value being read.

i believe the anomaly would then occur depending on how close the 2 events are in time, regardless of frequency.

in that case, precise counts can be needed even with low frequency. say you are a restaurant with 1 burger left. 2 folks order the same time, but you decrement the count by 1 only.

also anything involving monetary values, you definitely don't want to read stale values ever.

the db doesnt guarantee linearizability (assuming clock skew). even the post says stale counters values can be read.

Doesn't that mean that following use cases are not possible:

  1. keeping count of page views   
  2. vote count per ticket/post  
  3. like/dislike counts per entity

a reason to use highly scalabale db like Yuga would be to keep such counts.

what does the JDBC driver has to do with thread per connection in the database? jdbc doesnt care if you use threads or processes for the connection

seems like yugabyte, like postgres, also spawns a process per connection; thus requiring use of external connection pool

dotCloud and a lot of other PAAS platforms.

Its ironic since with Docker + Kubernetes, folks essentially are recreating their own PAAS from scratch, but wouldn't use a prebuilt one...

it would be nice to put a label to mark the 'HEAD' commit

that definitely seems to be the plan. this is the first step towards it.

To be fair, Redis itself still remains BSD licensed.

The other modules for Redis developed by RedisLabs [1] are under the new Commons Clause license.

The big 3 cloud providers provide Redis as a cache service and don't use these modules anyway, so their offerings will remain unaffected.

[1] https://redislabs.com/community/oss-projects/

Can you point to any reference that mentions the profitablity in established markets? All the articles I see say that unit economics remain unprofitable in all cases.

Can someone genuinely explain this: How is that Uber continues losing cash but is about to IPO, but when MoviePass tries to do the same, its about to go out of business.

it is unclear what this response hopes to achieve. it is mentioned in the post that our containers do crash. that should under no condition cause the underlying node to go down. this has even been pointed out by others responding to this thread. it is interesting though that none of the other issues in the blog post are bought up.