Soyuz has killed its own astronauts. Progress is an unmanned Soyuz.

Crew Dragon and Falcon will kill astronauts too. Much as I cheer for SpaceX and hope for a wonderful future, this really is rocket science and people will die. That is the price we pay.

It's actually pretty easy to prompt a visit from the army if you pop up on frequencies where you are not expected, in some countries. Never mind any nice citizen-consulting sunshine-respecting mostly-independent part of the Executive Branch like FCC. Guys with guns come.

There are more licensed hams today than ever before. Part of that is because we modernized the licensing rules and don't have a Morse code test any longer (for which I take partial credit). And they already have a commercial niche. Most of them have jobs. Many of us got those jobs because of the skill we developed through Amateur Radio. In general they pay as well or better than offering ISP service to the boonies.

We don't want to see commercial use of those frequencies, even if such use would help some folks get more equipment, because if that happened, there would not be room for Amateurs any longer.

You should consider that all of the ham HF frequencies together are smaller than one WiFi channel. And they have global range. So, if you offer a good bandwidth signal to some home in the boonies, you have potentially used up that freuquency for the whole world!

I really have noticed people who were looking for me, standing outside of the mailbox store looking confused.

I'm familiar with the Microchip implementation. This is a 300-MHz-class 32-bit processor. Not particularly modern and not really fertile ground for R&D.

We did have two or three suggestions from commenters of open MIPS processor implementations, some of which are more modern. One uses a proprietary high-level HDL, which I haven't investigated.

1. Don't use the compat version of jQuery then if you don't need to support old browsers. jQuery 2 exists for a reason.

2. Yes, JSONP is a way to transport data between different domains. Don't call domains you don't absolutely trust. JSONP isn't a fault of jQuery, but the browser security model.

3. jQueryUI is a different dependency. Don't use it if you don't want it. It really depends on your application though, if it's presenting a UI, then are you going to implement it all yourself, or pick one of the many UI JS libraries that will be in the same size ballpark. Browser downloads once, browser caches, job done - and these libraries are usually accessed from a CDN, so you probably already have it in your cache.

I found the commenter who posed this as a response to RISC-V interesting. The University of California at Berkeley has a completely public implementation, under the BSD license, without patents filed, which your effort appears to be positioned against.

It is a time-limit on damages, which is not the same thing as a time limit on lawsuits. There is still the potential to restrain an infringer who started 6 or more years ago from further infringement through the courts - and totally kill their business - even though damages for the infringement can not be recovered. And you can sue any other infringer.

Err, updating the DOM and making updates to small parts of the page as a result of Ajax calls within a front-end Javascript application is the right way to create modern web apps.

What you are advocating is the full page reload, which is a massive horror for many websites. The only use case for full page reload for trivial content updates these days is to serve another bundle of ads around the next bit of content, and single-article based websites where the content is most of the page (e.g., a news site where you are clicking between stories via category links and indexes of articles).

Seriously, many modern websites are a set of single-page applications (and maybe static pages). The only page reloads should be switching between these applications. [Page resources (JS, images, etc) should ideally be stored in a CDN if you can afford that.].

I think that Javascript devs need to learn more about creating a build process to minify and crush the JS dependencies into a single file, rather than which new framework to use for each new project they start.

If your build process takes your dependencies (from npm, for example) and then concatenates them, and minifies them into a single dependency, that saves bandwidth, http calls, and time. If it can do dead code analysis too, to remove those unused functions, then great.

From reading comments, etc, there seems to be an argument into splitting the Ajax convenience methods of jQuery out from the rest, as lots of developers use the former, but you don't need the other niceties such as the highly abstract and overhead inducing $('thing') notation. Perhaps the jQuery 3 work will go some way to fixing this anyway, as it will be far smaller in the non-compat option.

Check out My Gate Array Project if you haven't already done so. The EE work is done by Chris Testa KD2BMH, I mostly do systems programming and business but do a lot of design checks, etc.

Repeating the AC because he's posted at karma 0. That's "University of California at Berkeley", AC, but the rest of this is spot on:

Berkeley University is pushing really hard to get universities to adopt RISC-V (an Open ISA and set of cores) as a basis for future processor and architecture research. The motivation behind RISC-V was to have a stable ISA that isn't patent encumbered, isn't owned by one company, and is easily extensible (OpenRISC didn't fit the bill here).

I can see that ARM and MIPS would have a problem with this, especially as there is nothing particularly innovative or performance gaining about either ISA, and some recent RISC-V cores have demonstrated similar performance to some recent ARM cores in half the area. This is there way of fighting back against something open that stands to lose them significant marketshare.

Cool. Someone found us the agenda!

I get paid to train EEs within large companies on intellectual property issues, and to help the companies and their attorneys navigate those issues. Infringement is rife within software companies. Not because anyone wants to infringe, but because of a total lack of due diligence driven by ignorance.

You've made my point for me.

And any informed patent holder knows that any violation must be prosecuted, or the validity of the patent evaporates.

No, that's just the ignorance of the uninformed that "everybody knows", but it's wrong. You don't lose your patent from failing to enforce it. You might be confusing it with trademarks, which can go into the public domain if you allow them to become generic terms rather than specific brands. And you can sometimes lose the capability of being able to enforce against a specific infringer if you hold back until the market develops, that's the Doctrine of Laches. But you don't lose your patent. Nor would you lose your copyright due to failure to enforce.