One of the funny things about the Intel/Arm situation is that in many ways, it mirrors how Intel itself started out on low-end microcontrollers and microprocessors for PCs, and grew to displace pretty much everyone else for the high end supercomputers, data centers, and the like. For many years, it has been fairly apparent that the same thing was happening with Arm; when Arm thoroughly cemented its position on top of the smartphone market, it seemed pretty clear that they would eventually be able to push up into the laptop market and beyond, the main question was when.
Unfortunately for Intel, they've been hit by a couple of major blows in quick succession; Spectre and other microarchitectural vulnerabilities, and the fact that the mitigations wiped out a lot of their architectural advantages, their trouble with manufacturing at new process nodes, allowing AMD to take the lead from them on high-performance x86, and Arm finally catching up with them in the desktop/laptop space, and also starting to make some small inroads in the server space (though mostly on cost, not performance at the moment).
One thing which may have made them more susceptible to the innovators dilemma problem is the fact that they were already a victim of the second system effect with their Itanium failure. They poured a lot of resources into a major new ISA, and it was a flop and was replaced by the incremental x86-64. Despite that, their incremental improvements on the x86 architecture managed to wipe out all of the RISC competitors on the high end; so there's probably even more organizational oppositions to major new architectural changes which could have kept Arm at bay.
I think it's interesting that it has taken this long for RISC to really pay off. The whole idea behind RISC was to optimize the ISA for modern, pipelined, OoO architectures, but it turns out that for a long time, a bit of extra complexity in the instruction decoder wasn't that much of a price to pay, and things like Moore's law and other architectural improvements kept it mostly irrelevant as a competitive advantage.
But finally, Intel has run out of running room on process dominance, and other things have happened like hitting more power limits and software that's able to take advantage of more available threads and relaxed memory models. Once you start to try to run more threads, the extra cost and complexity of those decoders starts to add up, and the strong memory ordering constraints mean that your hands are a bit more tied on huge OoO dispatch.
Anyhow, Intel is still the biggest semiconductor company in the world, and they have weathered other major issues like the famous Pentium floating point bug, Itanium, and Spectre. It will take a lot to dethrone them, and with their revenue and market share, they can lose a lot of battles and invest a lot of money into new technology or companies before they lose the war.
But the last few years make it clear that they need some big wins soon, or they risk turning into the next IBM, slowly losing relevance as they milk their cash cows while the world moves on.
My dad had a similar story about a bug report. This was back in the day when terminals still used paper rather than CRTs; actual teletypes. The bug report was something like "if I print a page feed on such and such terminal model, it will catch fire."
The bug report form (which was paper in those days) had a few of the usual checkboxes and fields to fill in, including one for "is the problem reproducible?" That box was checked. Someone had actually gone to the effort of standing by their terminal with a fire extinguisher, running the same command and putting out the fire when it caught fire again.
It turns out the problem was in some software that emulated page feeds by doing repeated line feeds. Some overflow or underflow bug caused an integer to wrap around, so instead of advancing a few lines to the next page, it would try to advance thousands or millions of lines. This particular terminal model was a new, high speed one, so it would try to advance the paper really fast. It was using those perforated strips at the sides, with the pegs that went into the holes. The pegs and holes weren't perfectly aligned, so the pegs would sometimes clip the holes a bit, causing some bits of paper to shred and get kicked up as dust. Along with a spark, I don't recall if it was from the motor or just static buildup caused by the friction of the paper, and the paper dust would ignite, causing the terminal to catch fire.
I just love the image of whoever submitted that bug report, seeing the "is it reproducible" checkbox on the form, and standing by the terminal with a fire extinguisher to put it out while doing the same thing to make sure the problem was reproducible.
> so instead of advancing a few lines to the next page, it would try to advance thousands or millions of lines. This particular terminal model was a new, high speed one, so it would try to advance the paper really fast. [...] causing some bits of paper to shred and get kicked up as dust. Along with a spark [...] causing the terminal to catch fire.
Great story! It really gives a new interpretation to the classic phase "halt and catch fire." The original interpretation was the apocalyptic myth that the CPU starts switching the bus really fast, overheats the bus drivers, and eventually ignites the electronics, which doesn't make much sense. Now we have a more realistic one. To be precise, not "halt and catch fire", but "CRLF and catch fire"?
BTW, legends also say that the flammability of early printers was the origin of Unix's "lp0 on fire!" joke error message, which can still be seen in Linux for USB printers.
/*
* Get and print printer errors.
*/
static const char *usblp_messages[] =
{ "ok", "out of paper", "off-line", "on fire" };
The flammability of old printers came from a combination of paper dust, worn out printing ribbon and possible presence of a flammable cleaning solution IIRC.
So at the end of the day, it's more of a reality than a joke, sadly.
Don't let later-day internet revisionist history take the joy out of you. No matter what the Wikipedia warriors profess, it was real.
So much truth has been lost in the last ten years because people who didn't experience the past don't believe the things that happened; and if references aren't a link away, they tell the world things that happened before their time are false.
BTW, I was reading your Twitter the other day, and saw that you complained that Wikipedia doesn't have any information about TTY - only two paragraphs and nothing more. Now you are here, I have to tell you that you have accidentally set your browser's Wikipedia language to "Simple English" [0], which is a special edition of Wikipedia for English learners, it only has few editors, thus most articles are incomplete. On the other hand, the normal "English" Wikipedia has a fairly standard introduction to TTY [1], around 16 pages on my screen. You've missed a lot, don't forget to switch your language back to "English" if you haven't done it already ;-)
you have accidentally set your browser's Wikipedia language to "Simple English"
I don't understand how that could have happened, so I won't address that issue. But this leaves me baffled:
I was reading your Twitter the other day,
This has to be the single worst decision you've made this month.
As far as I'm concerned, my Twitter feed is write-only memory. The SMS equivalent of dev/null.
If you're ever tempted to do so in the future, reconsider. Go for a walk. Write some poetry. Make love to your wife. Do anything else. We get so little time on this planet, please don't waste what you have looking at what I have to say.
> If you're ever tempted to do so in the future, reconsider. Go for a walk. Write some poetry. Make love to your wife. Do anything else. We get so little time on this planet, please don't waste what you have looking at what I have to say.
The IBM mainframe high-speed printers from decades ago made it possible to overprint the same line several times.
My memory of this was fuzzy, but I believe when you sent lines to the printer, there was a control code in the first column to have normal printing or to overprint the last line:
|
v
line-of-text
+this-overprints-previous-line
There were all kinds of things that you could do that were non-optimal, like overprinting lots and lots of stuff until it wore out the paper or making many things print simultaneously. If you did too much, the printer would stop and open the cover - think a 5x5x8 box opening its lid.
To be clear - these were basically chain saws with hammers behind the chain all controlled by software.
Huh. That's an interesting question. I looked up the original LISP paper (http://www-formal.stanford.edu/jmc/recursive.pdf), and it looks like the -p convention hadn't been established yet at that point, none of the predicates have that suffix in the paper. But it does say this:
(LABEL, SUBST, (LAMBDA, (X, Y, Z), (COND ((ATOM, Z),
(COND,(EQ, Y, Z), X), ((QUOTE, T), Z))), ((QUOTE, T), (CONS,
(SUBST, X, Y,(CAR Z)), (SUBST, X, Y, (CDR, Z)))))))
This notation is writable and somewhat readable. It can be
made easier to read and write at the cost of making its
structure less regular. If more characters were available
on the computer, it could be improved considerably.[4]
----
[4] 1995: More characters were made available on SAIL and
later on the Lisp machines.Alas, the world went back to
inferior character sets again—though not as far back as
when this paper was written in early 1959
So at the very least, some of the syntactic conventions of LISP were mostly due to limited character sets at the time.
Trying to binary search through history to figure out when the -p convention was introduced, I checked the original Scheme paper (https://web.archive.org/web/20171201033214/http://repository...), which has some examples in Scheme as well as implementation code in MacLISP. It looks like the predicate convention wasn't really strongly established at that point; in a few places, they use variables with a trailing `?` in the Scheme code, but I don't see any use of a predicate convention in the MacLISP implementation code.
Going back further, the LISP 1.5 manual (second edition, 1965, though the printing was from 1979) has a number of numeric predicates with the -p suffix, but it does not make note of the suffix convention (https://archive.org/details/lisp15programmer00john/page/26/m... , free registration required). It does use a lot of language discussing "predicate" and use the term "p position of a conditional expression" (https://archive.org/details/lisp15programmer00john/page/22/m...), so the use of "p" for "predicate" rather than "?" seems to be somewhat well established. LISP 1.5 had a very restrictive syntax for identifiers, they were just alphanumeric.
So, I'm going to say that while it's possible that the usage of P for this purpose comes from substitutiong P for ?, all of the sources I've found seem to indicate that it stands for "predicate."
yes. the printers had 132 columns. you sent a buffer of 133 chars, the first being carriage control. blank was line feed, i forget what was page-eject/form-feed (1?? memory fuzzy). + was overprint.
As a student, I had a part-time job as an I/O clerk. (feed the card reader, file printouts). We disabled overprint on student jobs because it caused a lot of headaches from bugs. Form feed in an infinite loop was enough hassle.
The original IBM printer did not document + for overprint, it was the result of a logic optimization in the controller and someone discovered it. So IBM installed a field change order that disabled that function, but included a switch that for an additional monthly fee would upgrade your printer to a model that supported it.
The automatic openning of the lid at the end of a box of paper destroyed coffee cups on a regular basis.
Even better some of the early printers (e.g. IBM 1132) had a wheel for every character position, all on a common axle, so you told the printer which character you wanted, then set bit fields in memory for which positions to strike, then wait for interrupt and repeat until you have printed all the characters that were used on that line, then told it to advance. The timing for this was finicky, to the point that the cheap 1130 wasn't capable of doing this fast enough, which was solved by IBM by making it run at a higher clock speed when at interrupt level 1. As you might imagine many of those machines spent a lot of time at interrupt level 1 doing things unrelated to printing
Why do I still have this odd desire to have my own personal line printer? Something about reading printouts on green and white paper (sacriledge to flip it over to the white side) always made debugging easier. And the sound is the best!
> seeing the "is it reproducible" checkbox on the form, and standing by the terminal with a fire extinguisher to put it out while doing the same thing to make sure the problem was reproducible.
I don't think somebody would repeat the problem just because there's a field in a form. It's way more likely that he reproduced the problem again and again before determining that the LF was causing the fire.
That part is a slight amount of hyperbole for humor value.
But the fact of the matter is, the submitter did actually reproduce the problem enough times that they were able to effectively characterize the problem.
And that's what I love about this story. Given how many bug reports I get in which no effort has been put in to trying to reproduce, characterize, or minimize the problem, I love that this reporter was willing to do enough of that to file a good bug report even for a problem that caused a fire in a piece of expensive equipment.
I don't know about you, but if I ever got a bug report that says "do these things, and it will catch on fire," you can be damn sure I'd be trying to reproduce it with a fire extinguisher nearby. :P
Yes! This is why I love this story so much. I triage so many bug reports that don't even have the barest of effort putting in to reproducing or minimizing them, so it's like pulling teeth to figure out what the problem actually is.
The fact that someone put enough effort in to reproducing and characterizing a bug report for a bug that actually caused a fire is amazing!
Realistically the printer probably caught fire under normal operations, then they went through everything that happened leading up to it, one step at a time, to figure out what caused it to catch fire. That is what let them submit a bug report with "this causes it to catch fire" rather than, "Printer caught fire randomly."
In the process of narrowing down which command did it, they demonstrated reproducibility.
Yes, that's pretty much what I was picturing as well. Sorry if it didn't come through in the way I told the story.
But yeah, the part of this story that I love is that as someone who reads and triages a lot of bug reports, I'm always disappointed by how few people put in even the barest of efforts to reproduce and characterize a bug.
This person, on the other hand, spent the time and effort to reproduce a bug that would actually cause a fire, and characterize it well enough that it could be reproduced and fixed.
Mozilla absolutely has been helping to keep web standards in check. Maybe not to the degree that you would like, but if it were up to Google, we'd all have some ancient under-specified version of SQLite and LLVM encoded in web standards, as they tried to just drop those in for database storage and NaCL.
Mozilla pushed back on those, demanding documented standards that could have independent implementations.
WASM is the cross-browser, much better specified alternative to NaCL.
Formal standards in an executable language are by far the exception rather than the norm. For something with as big a surface area as web browsers, I'm sure they would cost an ungodly amount of time and money to complete. And while you may prefer to reduce the surface area to deal with this, no one wants to break compatibility with existing sites.
I'm a bit puzzled by what you actually want. Mozilla did scale back its investment in Rust, WASM, and the experimental browser engine Servo, to focus more on its core browser, in the recent round of layoffs. But the existing investment has paid off; a number of projects that started off in Servo, and were written in Rust, like the CSS parser and Webrender, are now part of Firefox, providing safe, parallel styling and GPU rendering. WASM is widely supported across browsers, providing an efficient compilation target which is much better specified and easier to work with than JavaScript as a compilation target, or something like NaCL.
And some of the other efforts, like Rust and WASM, have now achieved sufficient industry adoption that other companies are picking up the slack; Amazon, Microsoft, Google, Fastly, and others are all hiring and paying people to work on Rust and WASM full time.
It seems that other than funding Thunderbird development, Mozilla is doing what you want, but you somehow still seem unhappy with it. Why is that?
It does say "Every six months we have a meeting to revisit this policy. Email ... if you want to attend the next meeting."
It sounds like he's willing to listen to feedback about the policy, but would rather have focused time dedicated to discussing it rather than long drawn out inconclusive tickets.
Since most articles with titles like this can be answered with "no", I'd like to point out for anyone reading the comments but not the whole article that the answer in this one is "yes," since Apache Arrow targets a different workload and can be considerably more efficient for that workload.
Apache is weird. I'd imagine it's probably the most web server on the planet? Maybe second to nginx but it hasn't really mattered much for a long time. Guess it's probably b/c most ppl aren't configuring it themselves anymore and have moved on to different hosting setups.
I mostly reach for nginx as well, but apache2 is awfully nice for certain cases where you really do just want a simple, batteries-included setup for some task. I hit one of these a few years ago when I set up a code search tool at my org and the IT department wanted a reverse proxy in front of it that would do basic auth against our AD/LDAP backend.
On nginx, this was going to require either recompiling the whole server to enable to some non-default module, or delegating the auth to a separate script/process that appeared like it was going to be painful to set up, or implementing the whole thing in lua. On Apache, it was a 10 line config file and I've never had to think about it again.
(And yes, I know the article is about the ASF and not httpd, but I just wanted to respond to this comment in particular.)
The fact that you use the term "flesh of murdered babies" to refer to embryonic stem cells, which even the Catholic Church simply refers to as "aborted fetal cell lines", indicates that you've bought way too heavily into the right-wing American culture war.
But anyhow, to answer your question despite the terrible way it was asked, no, the Moderna vaccine did not use embryonic stem cells in its development or production. Some partners, such as NIAID, did use embryonic stem cells for in-vitro testing of the vaccine: http://phillycatholiclife.org/life-affirming-choices-3/covid..., but the Catholic church does not consider that to make the Moderna vaccine unethical, as it's its direct development and production have never involved the use of embryonic stem cells.
Flamebait and flamewar rightly get flagged. If you had something substantive and thoughtful to say on the topic, it might have been different (hard to say), but you didn't even try.
I have not flagged any of your posts, but remember that "free speech" means freedom from government interference with speech, not freedom from a particular community deciding that your speech is disruptive to that community.
I notice looking through your comment history that you spend a lot of time discussing abortion and gun control, the two primary culture war wedge issues in American politics, and which are mostly off-topic for a technology and startup focused discussion site.
I tried to answer your question in good faith, and hope that you appreciate the information, but I don't really think this is the best forum for discussing the ethics of embryonic stem cell research.
There are options for pro athletes after their athletic career, as trainers, speakers, organizers of amateur events, etc.
For the major US pro sports, some or all of their draft is from colleges in order to encourage post-secondary education and leave players with more options after their career. I'm not sure how many pro cyclists do college, but I knew some folks when I went to college who were fairly high amateur and I believe looking to go pro.
> Safari made third party tracking impossible by gradually fully segmenting everything - HTTP caches, LocalStorage, cookies, etc. -
I haven't been following exact features between browsers too closely recently, but Firefox's Tracking Protection has been around for a while and improving for years; and of course, Firefox is where AdBlock/uBlock originated. What does Safari provide that Firefox does not? How does it affect web compat?
> and Chrome made JIT exploitation and then Spectre attacks in JavaScript impossible by using process boundary separations and applying sandboxes to purpose built processes.
This feature has been a long time coming in Firefox, and it's still not all the way there.
But Firefox did just release an opt-in process isolation feature for Firefox, which applies stricter cross-origin controls for a variety of content, and in exchange gives web developers access to SharedArrayBuffer, the feature that needed to be disabled to mitigate Spectre attacks.
So site isolation is progressing, and the first iteration of it has been released.
> What awesome technical choices do you think Mozilla has made recently?
The development of Rust. Servo, which acted as an experimental testbed for a parallel browser engine and has led to its CSS parser, WebRender, and a number of other components being used by Firefox. Asm.js as an alternative to NaCl, which led to the joint development of WASM.
I appreciate that site isolation is in progress in Firefox, but it came out in Chrome two years ago (three now?). You're telling me that the soon to be released IE7 will include a pop-up blocker, so I should switch back to IE from Firefox.
> I haven't been following exact features between browsers too closely recently, but Firefox's Tracking Protection has been around for a while and improving for years; and of course, Firefox is where AdBlock/uBlock originated. What does Safari provide that Firefox does not? How does it affect web compat?
Firefox, like uBlock and AdBlock is list based - it forbids known bad actors. Safari is changing web standards to make tracking impossible, regardless of whether or not you are a known actor, and doing it gradually and carefully enough enough where breakage is minor enough that users don't complain. And Safari has less market share than Firefox. Look at e.g. https://webkit.org/tracking-prevention-policy/ for the principles and the other posts on the blog for details about the implementation. It's an industry wide change that a non-advertising funded browser company needed to push, and it just needed a real leader to push it. And that person turned out to be John Wilander (https://twitter.com/johnwilander). For whatever reason (I've given my thoughts above), I think Mozilla struggles to attract these sort of talented experienced mid-career people.
Rust is pretty cool, but Servo is pretty immature, and it seems like Mozilla just fired all those people. I dunno. I don't see a bright future there.
> Rust is pretty cool, but Servo is pretty immature, and it seems like Mozilla just fired all those people. I dunno. I don't see a bright future there.
Well, yeah, that's the problem.
Until now, I felt like despite its issues, Mozilla was mostly on the right track. There have been a few mistakes here and there, but it was fundamentally doing good work.
However, cutting Servo, and it looks like maybe Cranelift as well (not sure about that, but Dan Gohmen aka sunfishcode, who seemed to be one of the lead contributors, has been laid off) is a huge blow.
While Servo as a whole browser is pretty immature, a number of components of it were adopted by Firefox, such as its CSS parser, Webrender, its GPU accelerated parallel rendering engine, and more.
You had asked about what Mozilla had done recently, and I listed a few things. But it looks like they are cutting a lot of that. They mentioned focusing on wasmtime and the Bytecode alliance, but I don't see how cutting one of their lead contributors helps out with that.
And they seem to be slowly cutting the head count on Rust; it's less apparent because there are enough people not at Mozilla contributing, and some of the core contributors have been moved onto other projects which use Rust at Mozilla so while they're not contributing directly they are still somewhat involved; and some folks have left of their own accord.
But now it looks like some of those other teams are being cut, like Servo and at least some of the wasmtime team, so I really hope that more companies can put some more investment directly in Rust, as well as the WASM ecosystem.
Take a look at a recent snapshot of changesets and lines of code to the Linux kernel contributed by various employers: https://lwn.net/Articles/816162/
Arm themselves is listed at 1.8% by changesets; but Linaro is a software development shop funded by Arm and other Arm licensees to work on Arm support in various free software, and they contributed 4% of changesets and 8.8% by lines of code. And Code Aurora Forum is an effort to help various hardware vendors, many of whom are Arm vendors, get drivers upstreamed, and they contributed 1.8% by changesets and 10.1% by lines changed. A number of other top companies listed are also Arm licensees, though their support may be for random drivers or other CPU architectures as well.
However, Arm and companies in the Arm ecosystem do make up a fairly large amount of the code contributed to Linux, even if much of it is just drivers for random hardware.
And Arm and Linaro developers also contribute to GCC, LLVM, Rust, and more.
Unfortunately, font-variation-settings isn't supported by Firefox, Safari, IE, or older versions of Edge, so these settings only work for ~70% of users according to Can I Use.
It was a bit frustrating viewing this site on Firefox and not having any indication of why the settings weren't changing anything.
Of course, maybe that's because there hasn't been enough demand for it, and now that there is a font that's widely available which can use this, Firefox might finish enabling it (looks like there is a flag for it, but it's not enabled by default).
Support for font-variation-settings has been on by default since Firefox 62, which was released almost two years ago. Are you using a Firefox older than that?
Ah, sorry, I was looking at the wrong item on "Can I Use...", @font-face: font-variation-settings, rather than the "Variable Fonts" item which covers font-variation-settings outside of @font-face rules.
Unfortunately for Intel, they've been hit by a couple of major blows in quick succession; Spectre and other microarchitectural vulnerabilities, and the fact that the mitigations wiped out a lot of their architectural advantages, their trouble with manufacturing at new process nodes, allowing AMD to take the lead from them on high-performance x86, and Arm finally catching up with them in the desktop/laptop space, and also starting to make some small inroads in the server space (though mostly on cost, not performance at the moment).
One thing which may have made them more susceptible to the innovators dilemma problem is the fact that they were already a victim of the second system effect with their Itanium failure. They poured a lot of resources into a major new ISA, and it was a flop and was replaced by the incremental x86-64. Despite that, their incremental improvements on the x86 architecture managed to wipe out all of the RISC competitors on the high end; so there's probably even more organizational oppositions to major new architectural changes which could have kept Arm at bay.
I think it's interesting that it has taken this long for RISC to really pay off. The whole idea behind RISC was to optimize the ISA for modern, pipelined, OoO architectures, but it turns out that for a long time, a bit of extra complexity in the instruction decoder wasn't that much of a price to pay, and things like Moore's law and other architectural improvements kept it mostly irrelevant as a competitive advantage.
But finally, Intel has run out of running room on process dominance, and other things have happened like hitting more power limits and software that's able to take advantage of more available threads and relaxed memory models. Once you start to try to run more threads, the extra cost and complexity of those decoders starts to add up, and the strong memory ordering constraints mean that your hands are a bit more tied on huge OoO dispatch.
Anyhow, Intel is still the biggest semiconductor company in the world, and they have weathered other major issues like the famous Pentium floating point bug, Itanium, and Spectre. It will take a lot to dethrone them, and with their revenue and market share, they can lose a lot of battles and invest a lot of money into new technology or companies before they lose the war.
But the last few years make it clear that they need some big wins soon, or they risk turning into the next IBM, slowly losing relevance as they milk their cash cows while the world moves on.