2006 was... early. I don't remember when HCs were formed, but there's no way the internal ATS had any level of sophistication, if it even existed then.
(Admittedly this is all years before my time.)
2,385 karma · joined December 1, 2015
(Admittedly this is all years before my time.)
> Jaguar had 360 terabytes of main memory [and] was logging ECC errors at a rate of 350 per minute
Source: https://spectrum.ieee.org/how-to-kill-a-supercomputer-dirty-...
I wouldn't consider this to be a problem.
It's not meant to be a system to convict people incapable of defending themselves in a foreign court.
Plus, there are extradition treaties: countries A and B have to _agree_ to the conditions under which A will extradite to B and under which B will extradite to A.
> The proper process should be like this: if country A thinks that someone from country B has committed a crime against them then they should come to that country and prove it in a court without being able to add additional charges.
Courts in country B generally have close to zero understanding of the legal minutiae of country A. Ignoring jurisdiction questions, what you're suggesting is that courts in country B have to:
* understand the hierarchy of the legal system in A (what precedent is binding, what precedent is advisory),
* understand what is and isn't a law (e.g. if A is a common law jurisdiction and B is not),
* somehow reconcile legal procedures in A with legal procedures in B (e.g. when are you allowed to ask the judge to dismiss a case? what's an acceptable situation to ask for N more weeks for discovery? how much time is considered reasonable? who do you file paperwork with?)
* somehow decide what constitutes a qualified attorney (e.g. in the U.S., every state has its own qualification process for attorneys to practice in that state, so being admitted to the bar in Colorado doesn't mean you can practice in Florida, and this also extends to the federal govt)
In general it's good to assume that if there are millions of people in a given system, there are _reasons_ (not necessarily good ones, just plausible ones) the system works that way, particularly when it's a system you have zero understanding of.
My claim is that, given the finite amount of time allotted to mathematics in a secondary school curriculum, it's better to spend that time learning about medians/means, regressions, statistical tests, and so forth, instead of memorizing power laws and derivatives of trigonometric functions.
The analytical type of thinking that proof-writing is certainly useful, but you can make much the same argument of many other curricula, and besides, it's not like most intro calc courses even do any proofs. The vast majority of them, I would assert, are simply pre-med weed-out courses.
I still remember freshman year, showing up to the standard intro calc course, and dropping it as quickly as I could in favor of my uni's equivalent of Math 55 (i.e. the hardest u/g intro math course) because of how asinine I found the content...
Google data centers != Google cloud data centers
The two are logistically very different and consequently that means the types of workloads they host are also different. The latter is really for GCP usage only (both customers and Google-internal cloud infra necessary to host GCP). Compare https://www.google.com/about/datacenters/locations/ with https://cloud.google.com/about/locations.
When there are no issues, this works fine.
If there are issues? Be prepared to do the customer service tango, and hope that the person at check-in understands how $intermediary actually resells their stuff and knows the right knobs to twiddle, because otherwise you're shit outta luck.
That being said, the biggest hurdle in a re-architecture project like this is usually in the "n=1 -> n=2" stage, and "n=2 -> n=5" is a lot easier: once you add service #2, you learn how to set up telemetry, permissions, billing/chargeback, alerting, etc. The next few are just repeating the same process.
That's certainly true!
I'm not at 5 years yet in the industry myself, but I've definitely started to notice these patterns - the strategy vs tactics is a nice way to describe it :)
> Perhaps you haven't dealt with machines of sufficient scale—the abstractions really do come back together! The IBM z/OS kernel knows about draining+evicting hotplug NUMA nodes as schedulable resources (and doing health-checks to automatically enable that), in exactly the same way that Mosix or TORQUE or kube-scheduler knows about draining+evicting machines as schedulable resources (and doing health-checks to automatically enable that.)
Oh, this is interesting. My experience has been as a Google-internal user of Borg, where although the fleet is large, most of the machines are individually small enough that it's easier for us to simply evict a machine from the fleet rather than block a core. (The whole "commodity" server strategy, whereas z/OS follows a very different architecture, but I see exactly what you mean there.)
Understandably so, especially when you might need, say, an AWS permission to actually validate a config (or are there other distinctions between the two that I'm not thinking of?)
I wasn't previously aware of treesitter, but it definitely looks like the type of thing we eventually want to do!
One of the things we currently do is run our own daemon and LSP proxy, so that we can share functionality between the CLI version of our tool and the VSCode extension. Right now we treat most linters as CLI black boxes, but we're looking at moving to treat more of them as LSP servers (we currently do this with eslint, but don't yet with ones like clangd or tflint).
And there is indeed more that we're building out! The other product that we're actively prototyping (and dogfooding) is our merge queue: https://trunk.io/products/merge.
Long-term, the vision for Trunk is to make development overall a more seamless experience, by actually tying together the various disparate tools that solve individual problems that we run into.
> Either you just fail and ask the user to resubmit or you fix up the formatting on their behalf.
We only apply autofixes when running on the user's machine; when running on CI, as you point out, we only show them because of Git's decentralized nature here.
> The secondary problem is that the lint tool chain running locally sometimes doesn’t version match what’s in CI which poses a set of problems too, although in practice I think that’s raised as a concern only by teams that don’t establish good hygiene of checking in the set of tools (maintenance of multiple platforms is real there though).
We've built out our own system for managing (mostly) hermetic toolchain installs, and require users to version their linters in their trunk.yaml configuration right now. (There are some open questions here around how we handle version skew between our toolchain version and the system-installed toolchain version.)
We're also well aware of the problems that emerge as you scale to a larger team; hierarchical configs are one of the things that we've discussed but are waiting until we have more traction to flesh out. (All of us working on the linter side have experience setting tech direction for orgs of 100+ engineers).
The canonical example in my mind is any kind of autofix-able linter, where there's some kind of patch (or more nuanced autofix) that the linter can generate on-the-spot for you. With a sh_test construct (or any other test), you generally find yourself printing out some command that the user can run to fix things, which in a sufficiently large codebase can get really frustrating. (The worst offenders of this that I remember dealing with at Google were when generated code/artifacts had to be checked into the repo instead of getting being wired into the build system because <insert hermeticity problem> and a large-scale change you were doing looked at one of them the wrong way...)
(My company - https://trunk.io - is actually building a universal linter as part of our product offering, and we already have a system to write custom linters with varying levels of sophistication that can plug into both your IDE and CI system!)
Disclaimer: I work on trunk :)
(FYI: for anyone holding off on this because of issues with spdlog, enough has been fixed in the latest versions of both that you can upgrade them together now.)
Also worth noting: the UX of fmtlib's compile-time format strings is actually quite interesting. There are error callbacks in the consteval calls that take advantage of the context that compilers show in compilation failures that detail the mistake being made.
(Aside: I'd also like to note that `absl::StrFormat` has supported compile-time format strings for quite a long time. https://abseil.io/docs/cpp/guides/format)
> What is a SQL query planner but a compiler?
Kind of? Lexing, sure, and to some extent IR, but an execution plan is not built from an instruction set, especially when you start talking distributed. Even if you ignore the distributed scenario, there's still a huge difference between understanding indices/columnar-storage/row-storage and implementing PGO or LTO.
Plus, there's also a lot of domain complexity here- are you aiming for just ANSI compat, or are you going deeper and trying to be compatible with specific SQL Server / Oracle / Postgres features?
> Is an OS scheduler really that different from an HPC workload manager, or your GPU's computer-shader arbitrator?
Knowing little about HPC or GPUs, all I can say is that yes, there's absolutely a difference between the kinds of issues a kernel, hypervisor, and distributed scheduler have to deal with. Hypervisors need to integrate with higher-level RBACs, for one; distributed schedulers also need to be able to evict bad machines from the same system.
Telemetry also changes massively: if you're dealing with a kernel/hypervisor, stats from things like strace etc are useful. If you're distributed? You now have multiple cardinality problems (hostname, network devices, microservice release ID).
> Is RDMA against an NVMe storage pool fundamentally new to you if you've already written hierarchical chunk persistence+caching for a distributed key-value store?
Again, yes (at least I assume so, I'm not super sure exactly what "NVMe storage pool" is, I assume you're talking about the protocol that SSDs speak) - e.g. what's your resilience story against a network failure (someone cutting a fiber line, or losing a subgraph of a clos fabric)?
IME the best compromise I've found is to learn enough to recognize the problems, so that when I implement a bastardized compiler, I'm aware that that's what I'm doing and that at some point in the future I'll need to decide how deep the implementation should go or switch to actually using some library.
One of our products is a universal linter, which wraps the standard open-source tools available for different ecosystems, simplifies the setup/installation process for all of them, and a bunch of other usability things (suppressing existing issues so that you can introduce new linters with minimal pain, CI integration, and more): you can read more about it at http://trunk.io/products/check or try out the VSCode extension[0] :)
[0] https://marketplace.visualstudio.com/items?itemName=Trunk.io
tl;dr: we took a long time to realize that the Romans didn't use potable water, they used saltwater; the volcanic ash they had access to was also very important
From https://geneticliteracyproject.org/gmo-faq/glp-tackles-one-o... :
> [...] chemical/physical mutagenesis and a lot of other techniques are “unnaturally” performed “in the lab” but are not classified as GMOs.
while True:
...
if condition:
break
...