You can use free file fillable forms to submit online. It's a bit of work to transcribe from other software. It also requires a particular interpretation when filling forms (e.g. you need to round before summing your W-2s).
2,695 karma · joined March 2, 2013
Send hate mail and memes to eculperic@gmail.com
> The separation of concerns is deliberate — breakpoint() and is_debugger_present() are orthogonal building blocks, and breakpoint_if_debugging() is the convenience composition.
It might be a false positive or just a few spots. Or maybe it's rage bait. I'm sorry if the author actually writes with this style.
It's a little tricky with memory orders since you are synchronizing on two different locations. The simplest thing is to make all atomic accesses seqcst, but I think a single fence(seqcst) before checking overlap is sufficient in this case and will use fewer synchronizing instructions.
The overflow checks are also tricky. We want to make sure that if an allocation fails, subsequent allocations also fail (even on other threads), and overflow might allow them to think they succeeded by incrementing again back into a valid range. This means you generally can't use fetch_add in a thread-safe bump allocator and instead need to use a CAS loop where you detect overflow before writing.
Since you are doing a CAS loop anyway and always accessing both variables, it might actually be faster to combine both variables, especially if you typically allocate from both at the same time. E.g. if you pack two offsets into a 64-bit CAS word, you can still address 4GB, and you can get even more by aligning allocations. You also don't have to worry about seqcst.
Antitrust is also federal and is probably generally supreme over state law. E.g. even if Google fairly acquires talent according to state law, it can still be determined to violate antitrust.
This poaching scenario (where Big Co pays above market to a large number of employees to drive a competitor out of business) is very similar to dumping (selling goods below market etc.), which has been illegal for a long time even though "selling goods" is generally legal.
However, since the government (DoJ, FTC, etc.) is the ideal litigant, you actually need someone who works there to not get fired for long enough to complete investigation and enforcement. In a lot of anti-trust cases, all the direct participants benefit: the employees get paid more, Big Co consolidates power, and Small Co gets paid off. The "losers" are most distant like their customers or uninvolved competitors who aren't in a good position to sue.
At some point, there becomes a mathematical impossibility of too many pages of applications for too few evaluators who also have to do the rest of their jobs. Either they don't get quite that many applications, or the initial evaluations must be based on some incomplete reading (looking just at the resume, reading a subsection, skimming, or randomly discarding), or the backlog keeps growing.
Fwiw I also applied and the auto-reply said I should expect to wait 4-6 weeks, which has recently passed without hearing back. The application is a ton of work, and I don't mind doing it with a significant chance of being considered, but I think it's a normal reaction to be devastated if you put all that time and energy into crafting your materials, which manifest all your experience, behavior, and personality, and it turned out nobody read them. I still have a little hope, but I'm sorry you never got a response.
I.e. in order to get to the point where you didn't have to manually touch this thing, you likely did have to learn deeply about its underlying concepts by manually doing things.
Operating machines doesn't always have the same phenomenon. E.g. experience with a hand-powered drill is unnecessary to use an electric drill.
I'm also curious if it stopped after that goal or if it kept playing.
In a different vein, another thing TLA+ isn't great at is modeling atomics and in particular weak-memory semantics or anything that's not sequentially consistent. If you translate your algorithm to pcal, it will run as if it was sequentially consistent. If you need to model non-sequential-consistency, then that needs to be spelled out with explicit logic to TLA+, which is probably too complicated and error-prone to do by hand. The C/C++/Rust memory models permit a lot of wacky stuff. I imagine you need to add read caches and writeback buffers for each variable with cache-flushing instructions at appropriate points, but maybe there is a more elegant way to do it.
If you use rust, miri and loom both have analyzers that can check some non-sequentially-consistent behavior (and loom doesn't actually implement sequential-consistency at all).
The other line items are probably similarly unrealistic since they include their own launch costs as well.
They also spec 300 racks of 500kg each, which is <40% of the weight of the comparable land rack. I doubt the full weight reduction since the racks still need to survive launch force/vibration in addition to fluid/pressure enclosures that land racks don't require. I think it's likely that just about every part of this report has a similarly cooked numbers, and we can just throw the whole thing out.
These conversations get frustrating since one group is saying the dancing is bad, a second group is saying it's good (for a bear), and a third group is saying we are a few years from a bear-only dancing industry.
Bilbo's house is actually described in The Hobbit and the exterior isn't really described at all in Fellowship. The prologue of Fellowship (Concerning Hobbits) mentions hobbits like round doors and windows and the fact some hobbit homes are underground, but the turf-dome design here is not mentioned. It actually mentions hobbit homes typically have bulging walls, so unless you've read the The Hobbit, you might not picture this entirely-underground style.
In The Hobbit, his home is described as a (nice) hole in "The Hill" with a perfectly round front door and round windows, which could imply the design here.
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?
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.
static JsonObject of(Map<String, ? extends JsonValue> map);
static JsonObject of(Map<String, ? extends Object> map);
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).
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.
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).
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.
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.
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.