Not sure why you're getting down voted, but you're absolutely right. Cool project though.
1,857 karma · joined March 15, 2012
For example, in my local (semi-rural) area, private companies are exclusively doing it, along with other things like wifi. If government dollars are available, they always have strings attached and take decades to roll out and are typically really only issued to large companies with substantial ability to roll out large programs (with the exception of a few co-ops that have made the news).
And this completely ignores Starlink, which was repeatedly denied government funding because the government hates the viewpoints of the guy who runs it, but nevertheless offers the best opportunity for high-speed Internet in rural areas. It's just like when Cornelius Vanderbilt completely beat the Post Office's own selected "winner" to connect the two coasts via steamships.
And the total boondoggle that is your best example -- BEAD -- has, by its own admission, connected ZERO people since it was enacted in 2021! It's another ridiculous example of picking winners and losers, but mostly losers.
Please feel free to read the sad story at the government's own websites (the .gov's below) as well as a DC thinktank:
https://www.internetforall.gov/program/broadband-equity-acce...
https://broadbandusa.ntia.doc.gov/funding-programs/broadband...
https://www.washingtonpolicy.org/publications/detail/the-42-...
It should not the government's job to fund things that have a definitive and obvious competitive advantage for private industry, because they're just terrible at it.
Look back at the almost literally trillions of dollars that the government wasted in the solar or wind industry for other examples of where taxpayers' dollars might just as well be shipped on pallets to China or flushed down the drain.
Private industry beats government investment every single time, because the government doesn't actually have enough skin in the game and is so easily corrupted and influenced by lobbyists. When government dollars get involved, it distorts the incentives and then we end up with terrible things like AT&T controlling a monopoly that they didn't even pay for (like Ma Bell in the land before time).
You seem to be assuming that a $200 meal was the only compensation the person received, and they weren't just getting a nice meal as a little something extra on top of getting paid for doing their job competently and efficiently.
But that's the kind of deal I make when I take a job: I do the work (pretty well most of the time), and I get paid. If I stop doing the work, I stop getting paid. If they stop paying, I stop doing the work. (And bonus, literally, if I get a perk once in a while like a free steak dinner that I wasn't expecting)
It doesn't have to be more complicated than that.
In standard HTTP/1.1, any method can have a request body. In Representational State Transfer (REST) as defined by Dr. Fielding, HTTP doesn't even come up, let alone "methods" per se, so there is no distinction between DELETE, POST, or GET from a REST standpoint, only within HTTP as an engine for hypertext. Further, in HTTP, any of these requests can contain a request body.
But, because of this behavior by the WhatWG for Fetch, the IETF has added this paragraph to the specification for HTTP/1.1:
"A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request."
In other words, it's fetch that is non-standard, and the actual HTTP standard had to be updated to let you know that.
Fetch will reject your GET if it contains a body (a deliberate maintainer decision), even though it's entirely permissible by HTTP and done by many real-world AJAX APIs. Real AJAX will do what it's supposed to. (The HTTP 1.1 2014 Spec says that including a request body in a GET "might cause some implementations to reject the request." Guess which one!)
Also, advanced features like progress are completely absent from Fetch as well.
However, there are some fantastic libraries like Axios[1], SuperAgent (requires npm), and, yes, jQuery[2], that have really excellent API's (far superior to Fetch), or you could just write your own (or use an LLM) short wrapper around modern AJAX and call it a day. h/t to Claude:
const xhr = ['GET','POST','PUT','PATCH','DELETE'].reduce((x,m) => (x[m.toLowerCase()] =
(u,d,opt={}) => new Promise((r,j) => {
const q = new XMLHttpRequest();
q.open(m,u);
q.responseType = opt.responseType || '';
if(opt.headers) Object.entries(opt.headers).forEach(([k,v]) => q.setRequestHeader(k,v));
if(opt.signal) opt.signal.addEventListener('abort', () => q.abort());
q.withCredentials = opt.credentials === 'include';
q.onload = () => r({
ok: q.status >= 200 && q.status < 300,
status: q.status,
headers: new Headers(q.getAllResponseHeaders()),
text: () => Promise.resolve(q.responseText),
json: () => Promise.resolve(JSON.parse(q.responseText)),
blob: () => Promise.resolve(new Blob([q.response])),
response: q
});
q.onerror = () => j(new TypeError('Network request failed'));
q.send(d instanceof FormData ? d : JSON.stringify(d));
}), x), {});
Each method listed above returns a Promise that resolves with the XMLHttpRequest object or rejects with the error. So you get both the Promise functionality and full access to the XHR object in the resolution.
Usage:
xhr.post('/api', { data: 123 }, {
headers: { 'Content-Type': 'application/json' },
credentials: 'include',
signal: abortController.signal
})
.then(res => res.json())
.then(data => console.log(data));
And, if you don't need AJAX but do want some of the features from jQuery (like some of the more unusual selectors) that aren't in Cash (to save bytes!), AJAX (and special effects) is excluded from jQuery Slim which brings the code down to only 69KB[3].
1. Axios https://github.com/axios/axios (41kb)
2. jQuery AJAX https://api.jquery.com/jQuery.ajax/ (87kb but includes ALL of jquery!)
Those compliance companies are (mostly) all just checking a box. It's (mostly) security theater from people who wouldn't know security if it bit them in the nether regions.
Even if that wasn't true, there's probably no box in any compliance regime that says "Yes, we loudly promulgate our security failures from the nearest rooftop on 10am on a weekday" (and it's always five o'clock somewhere, right?)
If it helps (I know it doesn't), the Executive Branch likes to do this with poor job number revisions, too, lol
IMO, better to choose point solutions and combine them.
Your editor can handle everything way faster locally, plus it can grab files with SSH’s built-in (and mature to the point of being ancient!) capabilities: caching, compression, and instant text file downloads over an open connection. You can even check for remote file changes using stat.
Even better, use sshfs or another FUSE option.
There’s a ton you can do with plain SSH alone. This whole running-a-remote-server idea is, frankly, puzzling.
sudo strings /dev/sda | more # press q to quit
You're lumping together the data and access that SSH keys protect (which might be actually nothing) with the key mechanism themselves. The private key itself can be armored or stored in a Yubikey itself, or you can even use more exotic ways of protecting it.
The public keys can be easily automated while the private keys stay safe somewhere. Systems like SSH Universal Key Manager or Userify are out there (both on-prem, and Userify also has saas) to make maintaining the public keys across huge swathes of servers relatively simple (or sometimes extremely simple).
And not just authentication, but authorization, too (usually through something like sudo or doas). Or you can just roll your own with Ansible or LDAP (not nearly as flexible when dealing with two axis of variations - users and servers, but still doable). SSH keys being easy to manage is extremely important, because when things are hard to manage, people open security holes, either through ignorance or to save time.
So, like all keys, yes, SSH keys can be a massive security liability if not properly secured, but they're not so (intrinsically), or even by default.
Besides, there are multiple U.S. laws that already govern this, especially:
"No provider or user of an interactive computer service shall be treated as the publisher or speaker of any information provided by another information content provider." (47 U.S.C. § 230(c)(1)).
This law is a bedrock, foundational law that helps the Internet grow by protecting ISPs and providers from liability.
Lastly, the U.S. is a sovereign country. A judgment from another country would need to be fully adjudicated here under U.S. law or any applicable treaties like the Berne Convention, not Moldovan law. Otherwise, chaos would reign. You would end up defending yourself from random judgments from foreign courts with radically different laws or even completely different ways of looking at IP protection that you might not even be aware of or be able to defend yourself from. This would be grotesquely unfair and manifestly unjust.
Now, try to imagine that could happen for electricity. (It's the same reason why datacenters always have diesel generators.)
(perhaps ironically, Microsoft Edge supported it fully four years before Apple got around to it.)
(Side note: I have noticed that the prices on the big rig side of a truck stop are usually slightly higher for the same diesel fuel!)