singron

il y a 6 heuresdiscuss

Is there any evidence of division? Are all the vibe-coders going to some codeberg2? One of the main complaints is that the banned projects don't have human users proportionate to their activity, so if they all go to codeberg2, then that forge would just be full of projects nobody cares about.

Are there any projects on codeberg that are getting banned and actually have significant human interest?

If codeberg decided to kick out spammers, nobody would decry the loss, so what's being lost here? Is it strictly slippery slope?

singron

il y a 10 heuresdiscuss

TFA says the whole codebase is 600k, so that would be 1.8% dead code. IME dead code is much more common in larger codebases as figuring out that code is dead becomes more non-local and changes over time create dead code at a distance. I'm also not sure if the 11k was trivially dead (`if (false) { dead_code(); }`) or if it was more subtle (e.g. dynamically-dispatchable code that can't logically be called).

The 1.8% feels high if it's trivially dead. When I've run simple static analysis on decent codebases before, it's been much lower. For non-trivial dead code, it might be low. E.g. a lot of projects have piles of "dead" code behind ancient feature flags that would never be switched.

A small amount of dead code is fine. E.g. it might not be worth deleting utility methods that you happen to remove the last use of if they are simple and you might re-add a use later. Generated code is often dead since it's not worth specifying to the generator exactly what will be used. Other times, deleting dead code can lead to a valuable cascade of other deletions and simplifications.

singron

hierdiscuss

Currently, JsonObject.of has this signature:

    static JsonObject of(Map<String, ? extends JsonValue> map);

java.lang.String and other types don't extend JsonValue, and java lacks any trait-like way to add this functionality to existing types, so you would have to change the signature to this:

    static JsonObject of(Map<String, ? extends Object> map);

Now you can pass any Object in, but the typechecker can't ensure that it is convertible to json anymore. I.e. it will have to check at runtime that it's either JsonValue or another type that is has a known conversion for (Integer, Double, String, List, Map, etc.). The jackson ObjectMapper e.g. has a lot of configuration available to tell it how to do these conversions on arbitrary types, and I think they want to eliminate that kind of ceremony.

It does seem like any serious application is going to use another library, and this will be useful for very simple json usage or single-file hello-world type programs (e.g. to go along with Implicitly Defined Classes and the Flexible Launch Protocol).

singron

il y a 16 joursdiscuss

The system the fight is in experiences time-dilation, where everything slows down to 10% speed or even less. However, a few effects create a positive feedback loop that makes the problem worse.

All the surrounding systems still run at full speed. You can travel large distances and still arrive soon enough to matter in the fight. You can also die, respawn in another system, rejoin the fight, and barely miss anything. The positions in the fight therefore move even slower than time-dilation since ships on both sides are replaced so quickly.

Large groups have a massive advantage over small groups, so alliances are very large and join various alliances-of-alliances. The playerbase is often organized into only 2-3 major coalitions. At some points in history, nearly all the alliances have joined the same coalition, which leads to a strange pax-Romana called the "blue donut" (referring to all the ownable outer-systems being "blue" or allied with each other).

Also, nearly every player in a large fight just follows simple orders. Orbit A and shoot B. There are just a few people calling the shots.

Fights sometimes end just because people are bored, need to sleep, or go to work.

singron

il y a 18 joursdiscuss

That's interesting, although "read committed" here would be different from the isolation level of the same name. It seems really tricky to implement since tuples could be removed during a query. E.g. the backend could fail to chase tuple-id pointers, and there would be cases where it can be difficult to ensure a tuple is returned exactly once for a given scan.

If you use ordinary READ COMMITTED transactions, they will advance their xmin horizons on each query (and allow old version cleanups) up until their own transaction id but unfortunately not beyond that. For a given table, this is important since that transaction is uncommitted and it might modify the table. If you could make long-running transactions readonly on those specific tables, then you could use a different xmin horizon specifically for those tables. It would require a lot of duplicative bookkeeping in shared memory though. You could probably fake this today by using 2 databases on the same machine and using two-phase-commit+dblink/fdw for cross-database transactions/queries (fdw uses repeatable read in transactions, so it won't allow the xmin to advance).

singron

il y a 21 joursdiscuss

Pre-purchase, the customers are just looking at lists of features. Post-purchase, they realize the ovens burn bread and cake 10% of the time and pizza 100% of the time, and they just want a good working oven that doesn't burn food.

It seems like most customers are returning the oven, which would normally be an extremely strong signal that there is a quality problem. In the SaaS world, the equivalent would be churn, but it's not always as straightforward since if users quit before they sign up (e.g. by reading a review or using a free trial), then they don't show up in that metric.

singron

il y a 24 joursdiscuss

If you turn it off, it might attempt a 45 minute update when you start it again (yes this has happened to me with macos).

singron

le mois dernierdiscuss

Other companies were allegedly distilling the models by training on the reasoning output. By hiding the reasoning tokens, it makes it harder to do this. You can still try to distill the models, but you can't distill reasoning itself as well.

This could all be optics as well to try to give the appearance of a defensible moat. E.g. they can claim to investors that they are able to protect a significant chunk of their intellectual property this way. I'm not sure if anyone has a study about how significant the summarization is to distillation.

singron

le mois dernierdiscuss

I really wish there was an 80% kubernetes. I think you could get there with some changes:

1. No overlay networks. 1 IP per machine. pods use dynamically allocated ports, and the kubelet enforces pods listen only on their assigned ports using seccomp.

2. No kube-proxy or equivalent Layer-4 "load-balancer". It's not good, but it's often used. You should use some kind of Layer-7 load balancing instead. Also you need to look up the port number from (1). This also greatly lessens the need for DNS.

3. A better config language. YAML and helm templates are terrible. kustomize is built into kubectl, but it's frustratingly limiting and also still very complicated. Something like nix would have been great. This can make it easier to upgrade third party configs since you can have more logic to validate and merge your settings with upstream defaults or templates.

4. Maybe an EBF-like for the api server? If the built-in k8s objects don't have a setting for something, then you need to write an operator or control loop yourself and then run that too, which is a big lift. Over time, k8s just keeps adding more and more built-in things and then revising them, which creates a ton of churn. If you could easily script simple operations, then they wouldn't have to build in every permutation ahead of time. E.g. the HorizontalPodAutoscaler has 24 config object types with several fields each, but all it does is set replicas based on data read from the api-server, so it could be replaced by some kind of flexible script that runs in the control plane.

singron

le mois dernierdiscuss

If your working set is 20 TB, then it's pretty big. Each database has its own mix of hot/cold data, so it's impossible to compare without more information. A better measure might be IOPS. RDS has fairly low maximum IOPS unless you spend a lot more for provisioned IOPS or use Aurora.

singron

il y a 2 moisdiscuss

I have mysteriously lost comments/descriptions I wrote on issues. I figured it was related to a failed and lost opportunistic update like this, although I suppose it could have been caused by a fixable bug.

singron

il y a 2 moisdiscuss

I'm not sure this is true for Google. Ignoring their equity in Anthropic, AI is generally a threat to Google, since it's the closest thing to upsetting their search monopoly. The best case for Google is if OpenAI and Anthropic are way out over their skis, and Google is the only major player left with their sturdier financial position. The worst case is if ChatGPT/Claude completely displace search and nobody wants to pay for gemini. I find it unlikely that all three go down for the same reason.

singron

il y a 2 moisdiscuss

It's circular since Google owns part of SpaceX. According to [1] they own 7% of SpaceX, so a $1.75T IPO would value their stake at $120B. The target IPO price is >90x revenue, so if Google increases SpaceX's revenue by $11B, SpaceX's valuation could increase by $990B to maintain the same multiple, which would increase the value of Google's stake by $69B.

1: https://finance.yahoo.com/markets/stocks/articles/alphabet-s...

singron

il y a 2 moisdiscuss

I haven't worked there in several years, but assuming memegen hasn't wildly changed: Management likes having a pulse on employees, and they tolerate memegen since it's mostly fun, it builds shared culture in a massive company, lets workers (mostly) harmlessly blow off steam, and it would be massively unpopular to shut it down. Management does not like that memegen is often a nexus of cynicism and employee activism. Also in my experience, most employees were nearly completely agnostic or ignorant about whatever trend was on memegen, so it wasn't necessarily representative.

singron

il y a 2 moisdiscuss

After 5 years, you'll have an extra $1M in savings, and you can safely pay yourself 4% or $40k each year in perpetuity without doing any work.

This is also a really extreme version of the prisoners dilemma. In the standard formula, there are 2 prisoners, so it's somewhat practical to not defect, but there are hundreds of thousands of qualified candidates for working at Meta in these roles, so your personal decision to defect or not has likely no effect on the ultimate outcome. I.e. for the second option to work, you actually need to organize a unified labor movement with no defectors, which is probably impossible.

singron

il y a 2 moisdiscuss

These guard types are great and I've heavily used them in the past. But why codegen them?

E.g. the jwt auth example has some major problems since the verification rules aren't fully specified in the spec. The jwt-token verified rule only checks that the string isn't empty, but it doesn't actually verify that it is correctly parsed, non-expired, and signed by a trusted key. The authenticated-user rule doesn't check that the user-id actually came from the jwt. If you hand-wrote your constructor, you would ensure these things. Similarly, all the other constructors allow passing in whatever values you like instead of checking the connections of the real objects.

By calling the constructor for these types, you are making an assertion about the relationship of the parameter values. If AI is calling the constructor, then it's able to make it's own assertions and derive whatever result it wants. That seems backwards. AI should use the result of tenant-access to deduce that a user is a member of tenant, but if they can directly call `(tenant-access user-id tenant-id true)`, then they can "prove" tenant-access for anything. In the past, we have named the constructors for these types `TenantAccess.newUnverified`, and then heavily scrutinized all callers (typically just jwt-parsers and specific database lookups). You can then use `TenantAccess.{userId,tenantId}` without scrutiny elsewhere.

singron

il y a 2 moisdiscuss

Specifically it decrements the TTL of routed packets, so hotspot traffic will tend to have a TTL of 63 instead of 64. You could theoretically disable this at the risk of creating infinite routing loops, although android probably makes it inaccessible if the kernel has a setting for it at all, so you might have to rewrite packets in user space.

singron

il y a 3 moisdiscuss

Yes. The original Dapper used 64 bit trace ids and collisions were rarely a problem.

If you don't drop any spans from a trace, you can completely disambiguate a collision since the trace will have two distinct root spans. If you are missing spans, you might have a break in the parent-child links.

Even with infinite retention, your analysis will bucket by time somehow, so a collision might have no effect if the collision doesn't happen at a proximate time. If you are manually looking at traces, it will be very obvious there is a collision unless they happen at the same time.

Also, birthday paradox only expresses probability that there is a collision somewhere, but if you are filtering or looking at single spans, then the probabiliy that you actually see a collision is greatly reduced.

I think for basically all systems, an additional 64-bits has insignificant additional cost, so you may as well prevent collisions, but I think it could be a reasonable tradeoff if it mattered.

singron

il y a 3 moisdiscuss

I thought it was clear and am also surprised by the reaction (en-US speaker). "Is/are expected" is generally used as a passive-voiced form of "we/they predict" (obviously without having to specify a specific pronoun). E.g. "It's expected to rain tomorrow" means a weather forecast says it will rain tomorrow and usually not that people want it to rain tomorrow.

I wonder if this phrase has different connotations among other English readers? A lot of these comments are fairly early for US timezones.

singron

il y a 3 moisdiscuss

A specific process can use mlockall to keep all its mapped memory resident and prevent swapping or page cache eviction. That's what earlyoom does so that it can stay responsive when memory gets low. It's unfortunately underutilized in other infrastructure. It's also all-or-nothing: everything stays resident until it's munlocked regardless of how frequently it's used.

I had hoped that something like Linux Pressure Stall Information (PSI) would become more useful for low-memory scenarios. E.g. you could put critical processes in a cgroup that could rate-limit swap-outs/evictions so that it was always responsive. There are some cgroup knobs that affect reclamation, but you need a really good guess about how much memory something needs, which makes it hard to use.

https://docs.kernel.org/accounting/psi.html

Submissions

Nextdoor Slashes 25% of Staff in Latest Year-End Layoffs

Encouraging Inclusive Code with RuboCop

Facebook didn’t mark ads as ads for blind people for almost 2 years

New study: Software teams with more women communicate better

comments