I see references to John Gilmore being the original author of pdtar, and John Gilmore using the gnu handle, but I don't see any references to his usage of the name predating the GNU project or pdtar being referred to as gnutar before it became part of the GNU project.
I'm not saying that I disbelieve you, I just haven't been able to find any references for your claim.
No, the difficulty is based on the average rate of generation of blocks over the last few weeks.
If people put less computational power into generating blocks, fewer blocks will be generated. After each n blocks, nodes adjust their difficulty based on how long it took to generate those blocks, to try and achieve an average of a block every 10 minutes.
But how much computational power people are willing to put in depends on price. It only makes sense to mine if you get more out than you put in in the cost of buying the hardware, amortized over the life of the hardware, plus the cost of the power used in mining. If the price of Bitcoin drops, there are fewer people for whom it makes economic sense to continue mining, so some will turn off their miners, reducing the hash rate.
When global hash rate reduces like this, and the difficulty drops, then the people remaining will get more BTC per unit time from mining, so it can make economic sense for them to continue mining, as long as the price doesn't drop further. So indirectly, the total hash power of the bitcoin network is linked to the price of bitcoin; or, the price of bitcoin relative to the price of electric power.
> 3. Consequently, most of the processing units now deployed in 4-core-and-up machines are doing nothing most of the time but generating waste heat.
While it's true that most of the time a 4-core or more machine has idle cores, I'm not convinced this is a problem.
Yes, most of the time spent on a modern computer consists of doing things that aren't particularly computationally expensive. But our perception of the speed of a personal computer isn't based on some kind of steady state performance on batch jobs, I think that worst-case latency is a lot closer to how we perceive the speed of a computer. Of course, in specialized domains like HPC the steady state performance on batch jobs is important, but this article seems to be discussing personal computers.
Even if they come up rarely, you still hit computational bottlenecks at times when latency is important. Whether it's some bloated web page, some big Excel computation, a compilation for us programmers, or the like, there are plenty of times where you hit some kind of bottleneck in which you can make effective use of all of your cores, so even if 99% of the time you have idle cores, that 1% of the time can shape your perception of how fast your computer is.
And the fact that most of your CPUs are idle most of the time doesn't mean you are wasting power. Modern CPU cores conserve power when idle, via P-States (frequency scaling) and C-States (turning off idle cores).
It is probably true that there is a lot of software out there which could take better advantage of parallelism but doesn't, in some cases due to performance not being prioritized, in some cases due to some essential complexity of parallelizing the code, but also in many cases due to accidental complexity of parallelizing code due to unsafe languages like C and C++ that can make it quite difficult to refactor serial code into parallel without worrying about introducing significant bugs.
Any time this phrase appears in an argument it's a good indication that I can ignore the argument.
Our brains are not "wired." They are pretty malleable and adaptable, and while a lot of that happens during childhood, they do remain fairly malleable throughout life.
While there are neural structures that are specialized for certain tasks genetically, it is incredibly unlikely that the form of the book has had any significant evolutionary effect that would lead to some genetic predisposition for a book compared to some other form of conveying written information. Books have only existed for a couple thousand years, but originally were quite expensive to produce and only available to the wealthy; mass market production of books has only happened for a couple hundred years.
There are probably reasons why many people prefer physical books to e-books, but to make a claim that it's based on some kind of "wired" preference in our brains rather than practical factors like battery life, compatibility issues, screen refresh rates, or any of a number of other simple, practical explanations is a bit extreme, and would need to be backed up with some kind of evidence.
I personally don't consume much in e-book form, but the reasons are because of DRM, ecosystem lock-in, poor formatting in e-books, and the like. I actually consume a lot more content electronically than I do in dead-tree form, but it happens to be web pages and DRM-free PDFs.
> While there are neural structures that are specialized for certain tasks genetically, it is incredibly unlikely that the form of the book has had any significant evolutionary effect that would lead to some genetic predisposition for a book compared to some other form of conveying written information
It's the other way around. The book isn't better because we evolved for the book. The book is better because it evolved for us.
The key difference between books and e-books is that books are 3D objects giving us a sense of location for the information contained therein that varies in a consistent, logical manner as we progress through the information. This allows us to use our spatial memory, which yes, we are hard-wired to have, to help remember the information in the book. We evolved for this kind of memorization and are good at it.
> It's the other way around. The book isn't better because we evolved for the book. The book is better because it evolved for us.
But computer interfaces are evolving for us as well.
I'm not arguing that they are currently better; just that there isn't much about the form of the book that we are "hard wired" to prefer, but rather some inadequacies in both human interface as well as some other practical issues of e-book distribution.
The first paper you link is the only one that I would say really supports your point, but it only compares one way of reading on a screen (a PDF) against paper for a short document, and it doesn't probe very deeply into why reading comprehension was worse on the screen than paper. Is it the spatial location, is it the fact that you can spread out pages and see more at once on paper, is it the reduced eye strain from reflective vs. backlit presentation?
These are all things that could be relatively easily compared; provide paper with a scrolling interface rather than letting you turn the pages by hand, provide a paginated interface for the screen, use an e-ink display rather than LCD for the e-book case.
The second is about spatial memory of information on paper, but doesn't compare with a computer screen, and you can have a memorable spatial arrangement on a computer as well.
The third one compares paper to screen for proofreadig, but is from the 1983 and using white on black text on an Apple II. I think the differences in screen technology and UI design, along with the subjects having to learn a special purpose UI for copyediting on the screen, make that not all that relevant simply for the comparison of reading a book.
So anyhow, while there is some research on a screen being not as good as paper, it doesn't look like it goes into very much depth as to the reason for the difference, and whether it's based on spatial memory, deficiencies in UI on the computer, eye strain due to backlighting, or some combination.
Apparently, there have been rulings in the US that Apple and Qorvo (supplier of the modem chip in question) hadn't violated this same hardware patent, based on a detailed technical analysis. So there's a chance that this ruling could be overturned on similar grounds in Germany, hence the bond that Qualcomm has to pay against possible damages.
In the earlier licenses, "personal use" was just defined as the person using it being the same person as who installed it, and only one person remotely accessing the desktop at a time. So I had interpreted this as being OK for developer VMs in which the developer installs it themselves and uses it for their own development purposes. It also contained an "evaluation use" with a vaguely defined period.
The current license now defines "personal use" as explicitly non-commercial use, and adds more restrictions on client access that applies to any type of clients and not just remote desktop access, as well as explicitly defining the evaluation use period to being 30 days.
So while I didn't really have a concern about developers using VirtualBox with the extension pack previously, given the new license and the fact that they seem to be enforcing it via phoning home, it looks like it's time to set a policy of no one using it.
Luckily, we've already pretty much transitioned everything over to libvirt/KVM on Linux hosts, and people have generally been using VMWare or VMWare Fusion on Windows and Mac hosts.
Probably not at this point. If they had done this right when RISC-V was first announced, then maybe, as at that point they had the advantage of much more ecosystem and tooling integration.
However, it's now at the point where there are shipping RISC-V Linux distros, it's supported in GCC and LLVM out of the box, there are more than a dozen open-source RISC-V cores (https://riscv.org/risc-v-cores/, several of which are actually parameterized families of cores), and there are companies like SiFive offering commercially supported proprietary cores. There is hardware that has shipped from multiple different vendors, and that likely means that there are a number of others where it's fairly far in the pipeline.
With MIPS being behind Intel on the desktop and server market, behind ARM on the proprietary embedded core front, and behind RISC-V on the open source ISA and cores front, it's a bit hard to see why someone would buy MIPS who hasn't already invested in it.
If you want something more well established with a wider variety of cores available to purchase, you'd go with ARM. If you want something with no ISA licensing fees and even potentially no charge at all for an open source core, you can go with RISC-V.
I suppose there is some chance that MIPS could win some folks over from RISC-V for already having stable SIMD and DSP extensions, and more overall architectural maturity than RISC-V. But given that this seems to just be opening up the ISA without opening up any cores, and right now is a press release without having decided on the governance structure for the project or released any assets, while RISC-V has a number of fairly mature open cores including Rocket, BOOM, RI5CY, and more, and has a governance structure with a number of different companies involved, it seems like it will be a while if ever for MIPS to catch up on the open ISA front.
> China is rallying around the architecture with perhaps hundreds of RISC-V SoCs and dozens of cores in the works.
> “We are talking hundreds, if not thousands, of [RISC-V–based SoC] projects under way; it’s crazy … probably at least 40 to 50 companies or academic groups are dabbing in core development — some for internal use, some for open-source, and some commercial”
When I mentioned "multiple vendors," I was talking about hardware implementations that have actually shipped.
I've been looking for RISC-V chips that I can buy right now, and from what I can tell, there are only a handful. Two from SiFive (the E310 embedded processor, and U540 supervisor mode/Linux capable processor), one from GreenWaves (the GAP8). Turns out since I last looked (around the beginning of October) it looks like the Kendryte K210 has been released, also available in the Sipeed M1 module (https://www.cnx-software.com/2018/10/22/sipeed-m1-risc-v-com...). Anyhow, that makes 3 vendors shipping hardware implementations.
It's possible there are other special purpose chips not widely available for sale, or not advertised to English speaking customers, but I haven't found much evidence of them.
There certainly are a lot of RISC-V projects under way, which was what I was referring to by "that likely means that there are a number of others where it's fairly far in the pipeline." I think the "hundreds" from the article you quote is about total number of projects, not total number of vendors.
Some of these are just academic projects, some are multiple projects at the same vendor, and so on. I wouldn't be surprised if it was dozens of vendors that have projects at various stages of completion, however. I can imagine we'll be seeing a lot of releases over the next couple of years.
And there are a number of cores you can run on FPGAs, from high-end cores like BOOM that can be run on big expensive Xilinx FPGAs (or on Amazon's cloud FPGAs), to low-end like PicoRV32 that you can run on a $5 Lattice ICE FPGA.
> It's possible there are other special purpose chips not widely available for sale, or not advertised to English speaking customers, but I haven't found much evidence of them.
Take any established Chinese IT company, there are chances they are working on RISC-V based SoC or two. Alibaba - CK902, Huami - Huangshan No. 1, not talking about less known at the West vendors.
But it seems there are some considerations among established IT companies about not announcing RISC-V products very loud, especially in English.
> The Western executive, speaking on condition of anonymity, told us, “A lot of the biggest companies doing this are being very discrete indeed: perhaps they cannot afford to upset Arm.” He said they fear being told by Arm, “‘Oh, the core for your new smartphone is two weeks late.’”
These include instructions for saturating arithmetic (arithmetic that give the greatest or lowest possible values, rather than wrapping around), 16 and 32 bit fixed point, fused multiply add instructions, and some SIMD instructions https://en.wikipedia.org/wiki/MIPS_architecture#MIPS_DSP
There's a reason why I said SIMD/vector extension, since RISC-V first started down the SIMD route, but then they took a step back and decided that a vector extension might work better, so from what I can tell more work has been going into the vector extension than SIMD. But neither SIMD nor the vector extension are finalized yet.
I'm unaware of a MIPS vector extension, it seems to just have standard packed SIMD instructions, though I'm not that familiar with MIPS.
I'm not saying that I disbelieve you, I just haven't been able to find any references for your claim.
ChangeLog.1 and NEWS only go back to after it was migrated to the GNU project (http://git.savannah.gnu.org/gitweb/?p=tar.git;a=tree), his personal site, http://www.toad.com/gnu/ seems to be down but an archive (https://web.archive.org/web/20180623140434/http://www.toad.c...) just says 'In 1985 I wrote the "pdtar" program, which eventually became GNU Tar.'
He clearly uses the name "gnu", but did that usage predate the GNU project? I haven't found a reference for that.