LWN: Comments on "Some unlikely 2021 predictions"

Some unlikely 2021 predictions

Cyberax — Wed, 27 Jan 2021 00:02:21 +0000

On the other hand, it is cheaper on AWS than comparable Intel CPUs.

Some unlikely 2021 predictions

intgr — Tue, 26 Jan 2021 23:59:58 +0000

While this article demonstrates good value for the Arm-based AWS offering, the performance is pretty appalling. The Intel CPU has half the cores, was designed in 2017 and fabricated on 14nm technology, compared to 7nm for Graviton2. So with two hands tied behind its back, x86 still has comparable performance.

Percona is misleading a lot of people with this article.

Some unlikely 2021 predictions

marcH — Tue, 26 Jan 2021 16:51:58 +0000

> So the developers of the default desktop prefer refactoring and rewriting, on a regular basis actually, and the developers of the alternatives don't?

This is not about "default" vs "alternatives", it's only about having more choice and more competition.

> Because rhetorical questions suck

Especially the ones put in others' mouth.

It will become possible to submit kernel patches without touching an email client

Hi-Angel — Mon, 25 Jan 2021 11:37:03 +0000

> The article was in 2019, and since then the author haven't posted on the same matter anything. If you know if and where further discussions on that matter are happening, I'd love to know it.

So, I contacted the author and they pointed out to this project as the one working on that https://radicle.xyz/

I have also asked on their matrix channel and they confirmed. Quoting them:

> hi-angel:
> Hi, just wondering, are you folks the ones working to make this workflow real? https://people.kernel.org/monsieuricon/patches-carved-int...
>
> lftherios:
> Hey hi-angel Yes we are the ones trying to bring this vision to reality. Konstantin (the author of the post) has been very helpful to us during this process and heavily influenced our design with his thoughts and comments.
>
> One note: in comparison to the original post we don't use the SSB protocol but instead we designed a peer-to-protocol we call radicle-link that borrows a number of ideas from SSB.

Some unlikely 2021 predictions

jcm — Mon, 25 Jan 2021 07:34:51 +0000

I'm expecting Arm to have a clean sweep by 2030 of everything from phone to tablet to laptop to server. It will be a glorious day!

Some unlikely 2021 predictions

ms-tg — Sun, 24 Jan 2021 14:53:37 +0000

AWS instances with Arm looking good!

https://www.percona.com/blog/2021/01/22/postgresql-on-arm...

Some unlikely 2021 predictions

mstone_ — Thu, 21 Jan 2021 16:38:00 +0000

Yeah, free software's decision making progress is completely incomprehensible, compared to the corporate world where, say, google can decide on a simple messaging app and stay on message with no drama at all.

It will become possible to submit kernel patches without touching an email client

Hi-Angel — Sun, 17 Jan 2021 13:34:39 +0000

> People are working on it, see for example "Patches carved into developer sigchains"

Wow! This is an amazing article! FTR, the article is here https://people.kernel.org/monsieuricon/patches-carved-int... I really hope such instrument would put an end to disagreement between people who likes gitlab/github-based workflows and ones who prefer mailing lists.

> though if it would be in non-experimental use before the end of 2021 is a question.

The article was in 2019, and since then the author haven't posted on the same matter anything. If you know if and where further discussions on that matter are happening, I'd love to know it.

It will become possible to submit kernel patches without touching an email client

liam — Thu, 14 Jan 2021 03:50:30 +0000

I didn't say they would succeed:)

Some unlikely 2021 predictions

pabs — Wed, 13 Jan 2021 15:37:21 +0000

Comments from Hacker News:

https://news.ycombinator.com/item?id=25758976

Some unlikely 2021 predictions

floppus — Tue, 12 Jan 2021 22:43:45 +0000

But the opcode that would correspond to "SLL", despite being undocumented, does have a well-defined function: it multiplies the value by two and adds one. This is fairly well known among Z80 hackers (some people refer to this opcode as "SLIA" for "shift left inverted arithmetic", or "SL1" for "shift left and add 1".)

Sure, you can argue it'd be more parsimonious for the two opcodes to do exactly the same thing, but the undocumented function is occasionally useful to save a byte and four clock cycles.

Whether the undocumented function was intentional or not, who knows... but if it were unintentional, you'd expect that the result would be (x<<1)|(x>>7), or (x<<1)|CF, or (x<<1)|(x&1), or something even weirder, rather than (x<<1)|1.

If you simply want your assembler to emit an SLA opcode whenever you write SLL, that's an issue with the assembler, not the hardware. ;)

Some unlikely 2021 predictions

tao — Tue, 12 Jan 2021 13:59:03 +0000

Marble Machine X will finally be completed and Wintergatan will embark on a world tour.

Some unlikely 2021 predictions

pizza — Mon, 11 Jan 2021 18:51:23 +0000

A few years ago, "Arm China" went from a standard wholly-owned subsidiary of Arm to a joint venture which intentionally has 51% Chinese ownership. It was set up this way to help ensure China would not be reliant upon "Western tech", and to that effect it has what amounts to irrevocable licenses for already-developed cores as well as architecture licenses if they wish to develop their own cores. Plus a great deal of operational autonomy.

And recently, the whole thing has been scandal-plagued:

https://asia.nikkei.com/Business/China-tech/Arm-China-ask...
https://www.reuters.com/article/us-arm-china-lawsuit/arm-...
https://www.ft.com/content/f86a7ecf-8a6c-4be1-8c96-567f3d...

Some unlikely 2021 predictions

pebolle — Mon, 11 Jan 2021 18:35:33 +0000

> This would be true if divas^H developers liked to "focus" on fixing bugs. But they prefer refactoring and (re)writing on a regular basis. So some redundancy and alternatives are useful.

So the developers of the default desktop prefer refactoring and rewriting, on a regular basis actually, and the developers of the alternatives don't? Apperently the incentives for the developers of alternative desktop are totally different.

(Because rhetorical questions suck: I think the developers of the default desktop and the alternatives are basically subject to the same incentives. Except some of the developers of the default are actually _paid_ to fix bugs. And I expect the default to have less bugs than the alternatives anyhow, as it is being used much more often.)

Some unlikely 2021 predictions

plugwash — Mon, 11 Jan 2021 17:55:03 +0000

The question IMO is will the Chinese decide to fund Risc V development in an attempt to get it to the level where it is competitive with arm's higher-end cores. And if so will they be successful.

After the actions of the trump administration I would expect the Chinese to be wary of relying on western tech.

Some unlikely 2021 predictions

pizza — Mon, 11 Jan 2021 13:11:41 +0000

Is it possible? Of course. Is it likely? Nope.

There's nothing inherently superior about Arm or RISC-V (or even x86); CPU cores of equivalent performance require about the same overall internal complexity (and transistor count) and therefore cost about the same amount of money to develop and manufacture. Of course, it helps to re-use portions of previous designs (and their test suites).

In order for developing your own CPU core to be economically feasible, you have to have an astronomically high production volume to make the NRE cheaper than licensing an Arm (or one of the higher-performing RISC-V) core. Only a handful of players have this volume, especially on the high end.

Meanwhile, the rest of the SoC will cost about about the same amount of NRE no matter what the CPU core is, and of course the actual fabrication costs only depend on area/yield. (The actual CPU cores are only a small portion of a typical SoC's area/complexity)

Some unlikely 2021 predictions

marcH — Mon, 11 Jan 2021 10:32:50 +0000

> And moreover, by focusing on one desktop the chances of it suddenly sucking, to a distribution using it, should get even lower.

This would be true if divas^H developers liked to "focus" on fixing bugs. But they prefer refactoring and (re)writing on a regular basis. So some redundancy and alternatives are useful.

Some unlikely 2021 predictions

jezuch — Mon, 11 Jan 2021 08:06:11 +0000

Would it be possible for RISC-V to steal ARM's lunch?

Some unlikely 2021 predictions

jem — Sun, 10 Jan 2021 18:39:44 +0000

>Three instructions is not "logically complete".

Tell that to CPU architects. Motorola's 6800 had the same three shift instructions as the Z-80. The 80x86 processors also only have three shift instructions. The 8086 User's Manual states: "SHL and SAL (Shift Logical Left and Shift Arithmetic Left) perform the same operation and are physically the same instruction. ARM has the LSR, LSL, and ASR. RISC-V has SRLI, SLLI, and SRAI (shift right/left logical/arithmetic immediate). MIPS? Same thing.

It is a well known fact that an arithmetic shift only differs from a logical shift when shifting "right", i.e. towards the less significant bit positions. This has been known for decades, and I doubt the engineers at Zilog were stupid when they added these instructions. So to me, the *obvious* explanation was that Zilog copied the three instructions from the Motorola 6800, and left the op code that was left unused to do what it happened to do.

What Zilog *should* have done was to do what Intel did later with the 8086: document the assembler mnemonic SLL as an alias for SLA. Or used the name SLL instead of SLA.

>And ime, not being logically complete is *asking for trouble*. What happens if an assembler-writer uses SRL, and then also uses SLL because it's the logically obvious instruction?

What *I* think is asking for trouble is when an assembler writer jumps to conclusions about the instruction set. "Ah, there is an error in the documentation, Zilog forgot to document the SLL instruction. Ok, let's use the *obvious* opcode for that." And the ship the assembler without testing it.

>Do you have any *evidence* as to why SLL wasn't documented?

Do *you* have any evidence for your original claim? That Zilog didn't intend to design their processor according to industry practice at the time, and they really intended to define four shift operations, of which two are identical? And with a stroke of extremely good luck they could just drop the SLL instruction from the documentation, when they realized at the last moment that it didn't work as expected. What are the odds of that?

Some unlikely 2021 predictions

jezuch — Sun, 10 Jan 2021 17:10:10 +0000

Maybe yes, maybe no, but having gone on a two-week cycling trip this summer, I definitely understand where it's coming from. There are *lots* of days when I'd rather be back on the trail than "trapped in front of a keyboard".

Some unlikely 2021 predictions

Wol — Sun, 10 Jan 2021 16:59:14 +0000

Okay, SLA and SLL may have the same EFFECT. But as a mathematician I like symmetry. I would document both. And the instruction code for SLL can be deduced from the other three. Except it doesn't quite do an SLL.

So the question remains. WHY did Zilog not want SLL to be used? And I hate to say it, but the *obvious* explanation is it was buggy. Especially as the instruction quite clearly existed, and *almost* worked. Three instructions is not "logically complete". And ime, not being logically complete is *asking for trouble*. What happens if an assembler-writer uses SRL, and then also uses SLL because it's the logically obvious instruction? PEOPLE DON'T READ SPECS - THEY JUMP TO CONCLUSIONS, and it's very likely people will just assume SLL exists.

(I'm aware there was a whole bunch of 16-bit instructions that happily worked on pairs of 8-bit registers but weren't documented, and also I think 8-bit instructions that worked on the 16-bit registers, but I'm not aware of any other instruction that clearly should have existed and didn't.)

Do you have any *evidence* as to why SLL wasn't documented? Or are you just looking at what happened after the chip was released, and jumping to a different conclusion from other people?

Cheers,
Wol

Some unlikely 2021 predictions

excors — Sun, 10 Jan 2021 13:44:23 +0000

> I'm not a hardware expert, but my simplified and (probably) wrong understanding is as follows: You can't economically turn out perfect silicon every time. Instead, the production process has a certain percentage of errors, and you try to lower this percentage as much as possible, but eventually you start running into diminishing returns.

Also not an expert, but I think you're conflating two different classes of issue:

1) Errors in the design. Often bugs in the HDL code that defines the chip's behaviour and that were not detected by static analysis or by testing in simulation; sometimes bugs that are outside of the logic you were testing, e.g. a crypto block that leaks secrets to an attacker who's precisely monitoring the power lines.

If you discover those issues while running tests on real silicon, it takes many months and millions of dollars to fix the design and produce a new revision of the silicon. It's usually possible, and far cheaper and quicker, to develop a workaround in software(/microcode/firmware/etc), so CPUs typically come with lists of dozens or hundreds of errata that the relevant software developers need to be aware of. In extreme cases the workaround might be to disable a major hardware feature (like TSX in Haswell), though usually the workarounds are much less painful.

If you're producing a new revision of the silicon anyway (e.g. to fix an unworkaroundable bug, or for a new chip with new features), but you have a good software workaround for a particular errata, you might still choose not to fix that errata. 'Fixing' the design risks introducing new bugs (which may delay the new revision for months and cost millions more), so it's safer to leave it alone, and the errata can persist for a long time.

2) Random defects in the fabrication of each chip, because you're pushing the manufacturing technology to the limit and it's a messy physical process and the atoms don't all go where you want them to. In that case you can turn off (i.e. configure the hardware/microcode/firmware/software/etc to not use) the bad parts of the silicon, or run at a lower frequency / higher voltage that doesn't trigger the fault. You get chips with a lot of variation in capabilities and power efficiency, then the marketing people work out how to divide them up neatly and sell them at different prices.

All of those practices will continue because they're sensible economic tradeoffs, and because computers would be unaffordable if customers insisted on perfect hardware.

Some unlikely 2021 predictions

jem — Sun, 10 Jan 2021 11:14:31 +0000

>Similar to the Zilog Z80, actually, except they found the bug before it shipped - how many people remember (or realised) that although it had a RightShift instruction, it didn't have a LeftShift? They deleted it from the spec because it was buggy.

You are again repeating this myth that the "Shift Left Logical" instruction is missing from the Z-80 because it was found to be buggy. Yes, the Z-80 only has three shift instructions, SLA, SRA, and SRL. The SLL instruction is missing because it is not needed: the SLA (Shift Left Arithmetic) does the same thing. Only right shifts differ between arithmetic and logical shifts.

The Z-80 has a lot more undocumented instructions, none of which are bugs. They just work the way they do because of how the processor was wired. Zilog did not intend them to be used, but also did not want to waste silicon to disable them is such a simple processor.

Some unlikely 2021 predictions

Wol — Sun, 10 Jan 2021 09:46:54 +0000

I think you're missing a trick here, namely the diffference between production errors and design errors.

For example, I have a 3-core Athlon. I suspect it's actually a 4-core, but the fourth core failed QA and was disabled. Fine, I bought and paid for a 3-core, so I got what was advertised.

Spectre, on the other hand, was a design flaw - the chip did exactly what was claimed. The problem is it ALSO did something else ...

Similar to the Zilog Z80, actually, except they found the bug before it shipped - how many people remember (or realised) that although it had a RightShift instruction, it didn't have a LeftShift? They deleted it from the spec because it was buggy.

So some people investigated, and discovered that the instruction code for LeftShift actually did a LeftShiftAndIncrement :-) Which - I believe - found its way into the spec because people used it ... :-)

Cheers,
Wol

Some unlikely 2021 predictions

NYKevin — Sun, 10 Jan 2021 03:44:51 +0000

To be fair, this is a natural outcome of the economics of modern hardware production.

I'm not a hardware expert, but my simplified and (probably) wrong understanding is as follows: You can't economically turn out perfect silicon every time. Instead, the production process has a certain percentage of errors, and you try to lower this percentage as much as possible, but eventually you start running into diminishing returns. The manufacturer (hopefully) discovers those errors autonomously with a standardized testing process, but then you have to decide what to do with the bad silicon:

1. Throw it away (or recycle it, to the extent that it is practical to do so).
2. Turn off the bad parts of the silicon, and sell the portion you didn't turn off at a discount.
3. Use firmware or microcode to correct the problem, and (if performance is impacted) sell it at a discount.
4. Sell it as-is and hope nobody notices.

Option #1 is obviously the least profitable option, and options 2-4 can all be accurately described as "selling silicon with known hardware bugs." But IMHO only option #4 is actually dishonest. I also tend to imagine that #4 is rare, at least for the serious manufacturers. Consider how easily the FDIV bug was found - there's always going to be some person who is stress testing your hardware in a "weird" configuration, and if there's a bug, that person has a fairly good chance of finding it.

(OTOH, Spectre took multiple decades to find, and was endemic across the entire industry for that whole time, so maybe I'm a bit optimistic here.)

Some unlikely 2021 predictions

ms-tg — Sat, 09 Jan 2021 20:36:55 +0000

> 2021 will be remembered as the year of the ARM desktop

+1 to this. Year of the ARM desktop, laptop, server, and mobile. In other words a fundamental realignment where todays non-ARM x86 starts a slide from dominant to legacy to niche.

Would love to hear and understand contrary predictions!

Some unlikely 2021 predictions

Wol — Sat, 09 Jan 2021 17:30:44 +0000

"It only runs on a clean install"?

I bought a Terry Pratchett game for Win95 - I don't think I got much further than the first few "rooms" whatever they were. And inasmuch as I could find reports for it, it was very temperamental about the hardware, and advice was "re-install 95, install the game, don't install anything else". Not good news if you don't have a spare PC ...

Cheers,
Wol

Some unlikely 2021 predictions

mpr22 — Sat, 09 Jan 2021 12:22:27 +0000

> what would happen if everyone who bought a buggy video game demanded a refund?

It depends. How buggy is "buggy"?

It will become possible to submit kernel patches without touching an email client

nilsmeyer — Sat, 09 Jan 2021 07:00:37 +0000

> As of January 2021, it's not that hard to set up your own mail server, and configure SPF/DKIM/DMARC in a way that gives you good deliverability into Gmail/Hotmail/etc. I've had my own mail server for years.

I run my own e-Mail server, it's usually on auto-pilot with me just doing upgrades. But every once in a while an issue crops up, for example I only noticed that there was an issue with IPv6 after a friend told me and provided the logs from his server, I won't get that kind of service from gmail etc..

One of the first things I did as a young apprentice was to set up a new e-Mail / spam filter cluster for a small ISP so I have almost 20 years of this under my belt. The software stack didn't change much, still using Exim, still using Dovecot, replaced spamassassin with rspamd some time ago. Dovecot especially has been a joy with barely any need to do major changes.

> There are still tons of businesses running their own mail server or using something other than the Big Ones; businesses that do use Google, etc. will not be amused if they can't communicate with clients or vendors.

As long as Microsoft still offers Exchange on Premise that should remain the case. They could of course at any time decide that they really want customers to use their cloud instead. That worries me. At the same time Microsoft Outlook ruined e-Mail for a lot of people, I can always tell when I'm communicating with an Outlook User - full quote of all prior e-Mails, HTML signatures, the German version for some reason not using Re: but AW: for replies...

Some unlikely 2021 predictions

nilsmeyer — Sat, 09 Jan 2021 06:51:34 +0000

> The gaming industry already does this at the software level. For now, they have not yet realized that they can charge for the day 1 patch, but it's only a matter of time IMHO.

I'm not sure about that. So far the software world has been mostly untouched by it, but you have a legal right to get a product that is in working order when you pay for it. At the moment, software quality issues are often seen as force majeure, an accident. Even the language used is often invoking that image, "computer bug", "data leak" and so on. What it really is is often human error. And there are real costs associated - I'm mostly talking about the b2b sphere here but what would happen if everyone who bought a buggy video game demanded a refund?

It will become possible to submit kernel patches without touching an email client

Cyberax — Sat, 09 Jan 2021 02:35:07 +0000

There are companies that sell you pre-configured mail servers. They are not doing well.

It will become possible to submit kernel patches without touching an email client

liam — Sat, 09 Jan 2021 02:26:08 +0000

But if the big mail-providers EE&E in a way that screws us over, how many of us know how to set up our own mail servers?

Every problem can be rewritten as a marketing opportunity.

Email Servers

zlynx — Sat, 09 Jan 2021 01:31:06 +0000

For those of us that have done email for years setting up everything does seem pretty easy. But coming into it cold is hard. New people don't know everything or how it needs to work together.

But, I do remember some useful Linux Journal articles. There may have been a LWN article or two as well.

I do mine on Fedora Linux with Exim, Cyrus IMAP, and SpamAssassin. Exim needs to be configured to deliver to Cyrus properly. At one point I had to adjust the SELinux rules for that but I think that's part of the Fedora packages now. There's also SSL certificate configuration that has to be turned on and adjusted to work with LetsEncrypt.

And then there is DNS with MX, SPF and DKIM and DMARC stuff. And I enabled DNSSEC on my domain which I've heard gives you another few bonus reliability points.

And if you cannot get a static IP then you have to do all of this in the cloud, and optionally configure a VPN and forward your email servers to your home network.

It will become possible to submit kernel patches without touching an email client

dskoll — Fri, 08 Jan 2021 22:27:00 +0000

As of January 2021, it's not that hard to set up your own mail server, and configure SPF/DKIM/DMARC in a way that gives you good deliverability into Gmail/Hotmail/etc. I've had my own mail server for years.

I can't see the Big Providers changing this any time soon. There are still tons of businesses running their own mail server or using something other than the Big Ones; businesses that do use Google, etc. will not be amused if they can't communicate with clients or vendors.

This may change in the future, but not for a while, I think. There... that's my reckless prediction for 2021.

Some unlikely 2021 predictions

Wol — Fri, 08 Jan 2021 20:55:08 +0000

As a SUSE/KDE user, KDE$ was to me a disaster - I abandoned KDE.

My main desktop was an Athlon Thunderbird (K8?), and I simply couldn't log in. I don't know how long it took to go from login screen to usable desktop - I think the longest I waited was 24-36 hours before I gave up.

I went back once I managed to fix it (gentoo is wonderful here :-), but disasters like that cost you users...

Cheers,
Wol

LWN's Predictions are useful food for thought

ber — Fri, 08 Jan 2021 16:59:29 +0000

Jon,

your predictions are a good idea, because they help to step back a bit and get ideas about the larger picture! Thanks for so many years of LWN and its predictions!

(I know there was some irony in the introduction about this not being a good idea. But nobody stated why the predictions are useful - they are and it is not about being correct.)

Some unlikely 2021 predictions

rhdxmr — Fri, 08 Jan 2021 15:26:32 +0000

BPF will gain more popularity in container environment and there will be a few BPF conferences offline.

Some unlikely 2021 predictions

idealista — Fri, 08 Jan 2021 10:45:51 +0000

The predicton from a year ago:

https://lwn.net/Articles/808260/

Some unlikely 2021 predictions

ecree — Fri, 08 Jan 2021 04:34:35 +0000

Even if it is, I think our communities are robust enough to cope if someone key retires.

Unless it's Jon. I don't know if I could get through the week without a dose of his wry yet informative humour :)

It will become possible to submit kernel patches without touching an email client

ecree — Fri, 08 Jan 2021 04:27:33 +0000

> It's not as if SMTP is owned by anyone.

But if the big mail-providers EE&E in a way that screws us over, how many of us know how to set up our own mail servers? And how likely are we to learn in the meantime, given that interoperating with the big networks is already a massive PITA? (Alexei was already worrying about this back at netconf ’19, see http://vger.kernel.org/netconf2019_files/netconf2019_slid... — "Email is dying".)

So yes, if Gmail etc. become unusable for kernel development, it would be *possible* for us to set up an entirely parallel network of "engineers' email", that doesn't follow Gmail et al's lead on whichever of DKIM, SPF and DMARC it is that makes things hard. But it wouldn't be *easy* and it wouldn't happen overnight. Company IT departments won't support it on their email servers, because their first priority is keeping the executives' email working. (Maybe some of them will run a second server for the engineers. But I think we've all encountered enough corporate IT to be pessimistic about that.) And we can't start switching now, because we need to keep supporting developers who are on the existing systems (which are very picky about whom they accept mail from).

I like the email workflow and want it to continue. But unless we can square this circle, sooner or later it is going to blow up in our faces.