CoffeeDregs

I agree that it could get fairly complicated but these seem like the two propositions to me:

Un-normalized: $6T + interpretation + understanding + doubt that it's really $6T.

Normalized: $60k (get the GAO to provide a standardized number) + interpretation + understanding.

I get that it's imperfect but I have a hard time understanding how the "un-normalized" version is more-perfect or more comprehensible than the "normalized" version.

I suspect politicians would hate my suggestion: they've acclimated us to nonsense numbers. Per Dirksen (maybe): “A billion here, a billion there, and pretty soon you're talking real money." Again, I'm not pro/con high-speed rail but: CA probably has 15M taxpayers; estimates of high-speed rail ranged from $30,000M-$100,000M; how in the world was a CA taxpayer to recoup $3,000-$10,000 of cost? Put in those terms, it's a lot easier for me to think about the proposition.

I definitely think a Covid bailout was necessary. I do have some questions about where my $60k went...

I think I agree but with the point "Isn't this a solved problem?" I'm not sure if the first library should be written in C, Rust, C++, etc but it seems as though very similar libraries-but-in-different-languages are being repeatedly written.

I certainly get that a good library yesterday might not be good today or that an existing library's style might not meet this language's style but I doubt the need to rewrite existing libraries so often. Even with the much-maligned PHP, libraries were frequently bindings to other libraries.

Sure but you can't shebang all of the deps... Unless your `normal executable` embeds a Python dependency-manager.

Just in case someone RTFA and gets worried: this is breathless FUD and could be handled much more usefully in some other fashion that invites discussion of pros/cons (such as is happening on HN but I doubt the gist will be updated...). Wayland is an 0.99:1.00 replacement for x11. I would appreciate a succinct "Wayland changed X, Y and Z and that will affect applications A, B, C" but TFA isn't that.

Much like systemd, Wayland sounded as though it might have some serious wrinkles but those, as with systemd, never really materialized for me (a power user on a powerful machine). Most issues I experienced were transient as applications caught up with the switch (mostly screen sharing). Even though it's not too important to me, games (wine and native) are working better than ever on Linux (and Wayland).

I think the two persistent "issues" I've seen are: graphical ssh (X-over-ssh); and, maybe, others screen drawing on my screen in Slack calls.

I trust the arguments from the x11/Wayland developers and, AFAICT, Wayland has been a Good Thing but some eggs were broken to make the omelette...

I'm baffled that any developer uses a Mac. I know, I know... BSD, 3-finger swipe, but-they-wrote-the-ux-guide. But I've been running Debian Testing for 15 years now with nary a problem (on thinkpads, latitudes and desktops) I guess I'm weird in that I think gnome 3 is swell.

CI handles xCode. Otherwise, my 2x 42" 4k monitors, Gnome and works-here-same-as-the-cloud self reads these articles on puzzlement.

I can't count the times I've helped developers deal with oh-yeah-brew-is-weird-about-libpq. Now this? It's the avocado-toast of developer workstations...

This is a good, balanced article. I've been of a similar mind for over a year now.

The chances of the CCP releasing a self-harming bioweapon in order to harm the US seems silly. But an accident involving a well-intentioned gain-of-function experiment seems quite possible and was something that the US was concerned about with its own gain-of-function research.

In any case, this, like so much of this other nonsense around Covid [lockdowns in Contra Costa County when the major hospitals were empty-ish; no gradual escalation of lockdown given mid-January knowledge of Covid], seems pretty amenable to a calm, clear analysis...

    Hypothesis                    | Evidence                               | Likelihood
    ------------------------------+----------------------------------------+-----------------
    CCP Virus                     | [That'd be 360 degree dumb of the CCP] | *low*
    Gain of function lab accident | [Existing concerns and experience]     | *moderate*
    Zoonotic transfer             | [No likely vector for extant virus]    | *moderate-low*

Doesn't seem too difficult...

This looks a bit like the old (2000s) work of Leopard Logic or Tensilica. Exciting stuff.

One important note (based on some comments here): generally, these in-CPU FPGAs have very fast reconfiguration. Not sure if it's 1, 10 or 100 cycles but it's not milliseconds. Actually, (in past examples) configuration might take milliseconds but it would load a number of planes of configurations: plane 0 might be MP3 audio device; plane 1 might be MPEG2 video device. Then reconfiguration is: switch to plane 1.

This AMD proposal looks like it's much more tightly integrated into the CPU so it's got to be even faster. Combine that with the deep knowledge of processor internals you'll have to have to code for this thing and I'm having a hard time seeing you and me having much luck tinkering. This is probably 99.99% data center with gnarly NDAs and field support.

"Instead of drawing down our gold reserves, however, we gradually draw down our domestic manufacturing base and it gets replaced piece-by-piece in foreign countries."

To me, this is the money shot. I hadn't seen this expressed before and it makes perfect sense. I'm baffled that we (the US) caused this to happen to the US. I'm (unhappily) registered Republican but I argued vociferously to a Dem friend in 2000 that our inability to manufacture critical components was going to kill us. Kind of literally: AFAIK, the last LCD panel manufacturer in the US closed around then and we could no longer manufacture LCD for our military vehicles... (Even if this anecdote is untrue, the point remains valid...) I argued that, even in the presence of free trade, a country should have the ability to tariff imports to the extent that that country could maintain a 25% (or something) domestic market share.

Finally. I made a very similar suggestion to the ECS product manager about 5 years ago. We were moving from Mesos to ECS and I was losing the ability to manage Docker containers on our on-premises servers so I suggested allowing us to run the ECS Agent on our on-premises servers. This would allow us to centrally manage those servers and would get AWS into our on-prem infrastructure...

Technical debt is like credit card debt: it's high interest; it's not a huge issue if you use it wisely; and you have to track its usage and level against your total code/assets.

Like credit card debt, too many people turn around and they've got $20k of credit card debt or 20k LOC of tech debt.

I don't have too much of a problem with tech debt as long as: the benefit is clear; the debt is well understood; the payoff date/cost is planned. Just last night I was talking with a developer who works for me: "This way will require 5 queries instead of 1. Can you help me figure out this whacky ORM API to do it in 1?"; "Just do it as 5 right now and, as we learn more about the ORM API, we'll fix it later..." Tech debt: we get the product done faster; we've got a 1-5 line change to make (when we know how to make it); and we'll do so in a few months.