Linux 4.16 arrives, keeps melting Meltdown, preps to axe eight CPUs

Linus Torvalds has pulled the trigger and released version 4.16 of the Linux kernel, thereby killing off his own suggestion this release might need an extra week to mature. And here's some fair warning: version 4.17 is set to remove support for eight CPU architectures. That would mean Linux will no longer officially work on …

[John Smith 19]

And so fairwell blackfin, cris, frv, m32r, metag, mn10300, score, and tile.

Of which I only even recognize Blackfin (AMD?) & Tile (IBM?)

Designing a "better" architecture (for some task) is not that difficult.

Designing a better architecture others will buy. Not so easy.

[Michael H.F. Wilkinson]

Re: And so fairwell blackfin, cris, frv, m32r, metag, mn10300, score, and tile.

Tile64 and its kin were from Tilera, since acquired by some other company. Interesting 64-core design, with each core a MIPS-like processor, but I never spotted one in the wild.

[Anonymous Coward]

Re: And so fairwell blackfin, cris, frv, m32r, metag, mn10300, score, and tile.

Some of those are CPU with very specific uses - where they are deployed, there are no reasons to use Linux, there are specific OS, often real-time ones or very compact ones, that are more useful.

[steelpillow]

Re: And so fairwell blackfin, cris, frv, m32r, metag, mn10300, score, and tile.

One wonders why Linux was ever ported to them in the first place.

[Omgwtfbbqtime]

Re: And so fairwell blackfin, cris, frv, m32r, metag, mn10300, score, and tile.

because it could be?

[Mage]

Re: And so fairwell blackfin, cris, frv, m32r, metag, mn10300, score, and tile.

Blackfin needed Linux. But really ADI needed to either buy a CPU company or abandon Blackfin core long ago for a standard ARM core. I think it's sort of ARM like?

Never heard of the others.

[Anonymous Coward]

Re: And so fairwell blackfin, cris, frv, m32r, metag, mn10300, score, and tile.

>One wonders why Linux was ever ported to them in the first place

CRIS was used in Axis IP cams, which run Linux

[Ken Hagan]

Re: And so fairwell blackfin, cris, frv, m32r, metag, mn10300, score, and tile.

If you've got a new chip, no-one supports it yet. Porting Linux is something you can do to prove it actually works. Supporting that port for a while proves that you are still supporting the hardware. You are never going to sell the hardware unless you can convince customers of both of those things.

[dgc03052]

Re: And so fairwell blackfin, cris, frv, m32r, metag, mn10300, score, and tile.

>>One wonders why Linux was ever ported to them in the first place

>Porting Linux is something you can do to prove it actually works.

Exactly - same reason I once worked on a port of X-Windows to the write-only frame buffer of the F22 Cockpit display subsystem.

Although it really sucked if the login prompt showed up while flying the full-up simulator...

[Gene Cash]

Re: And so fairwell blackfin, cris, frv, m32r, metag, mn10300, score, and tile.

> write-only frame buffer of the F22 Cockpit display subsystem

And the funny part is I hear that runs on nvidia hardware... seriously

[John Brown (no body)]

Re: And so fairwell blackfin, cris, frv, m32r, metag, mn10300, score, and tile.

"One wonders why Linux was ever ported to them in the first place."

"Because it's there"

[DropBear]

Re: And so fairwell blackfin, cris, frv, m32r, metag, mn10300, score, and tile.

"Because it's there"

How odd the same never seems to apply to certain other contexts like eg. "why wash those dishes"...

[Alistair]

Re: And so fairwell blackfin, cris, frv, m32r, metag, mn10300, score, and tile.

Ahhh DropBear, I see your sprog(s) have reached teenagerhood.

[Doctor Syntax]

Re: And so fairwell blackfin, cris, frv, m32r, metag, mn10300, score, and tile.

"One wonders why Linux was ever ported to them in the first place."

They may be - or may have been - employed in embedded systems where the firmware was Linux but which hasn't been updated. If the vendors are still shipping Linux 2.x with a GCC that's not been updated in the last 10 years or more there's no likelihood that anyone's going to scream because it's been dropped from 4.x If in future they really want to skip to current kernels they're going to have to do a lot of work on compilers first.

[Chewi]

Re: And so fairwell blackfin, cris, frv, m32r, metag, mn10300, score, and tile.

> Of which I only even recognize Blackfin (AMD?) & Tile (IBM?)

Blackfin is Analog Devices, not AMD. I have one such box sitting here. With no MMU, it's not the easiest thing to run Linux on but it has some analogue phone ports, which are usually quite expensive. I now have a broadband-only line from A&A but I had toyed with the idea of hooking this box up to the phone port on my alarm system so that it could trigger a bunch of other things in the house when the alarm goes off!

[John Smith 19]

Blackfin is Analog Devices, not AMD.

I stand corrected.

I thought Tile was something to do with IBM (some kind of co processor?)

[Neil 38]

Doesn't Mikrotik run on Tile?

I believe Mikrotik's own hardware runs on Tile processors, and doesn't RouterOs run an embedded Linux kernel?

[rh587]

Re: Doesn't Mikrotik run on Tile?

> I believe Mikrotik's own hardware runs on Tile processors, and doesn't RouterOs run an embedded Linux kernel?

The Cloud Core Router range appears to. Most of the RouterBoard products as well as the CRS line are on MIPS chips though.

That said I don't think RouterOS is even using a v4 kernel. They're not on a bleeding-edge release so as and when they get to updating the linux kernel they ship with, they'll have to use 4.15 for the CCR line until the TILE hardware goes EOL.

[Missing Semicolon]

Re: Doesn't Mikrotik run on Tile?

...plus, of course, the lack of source availability means that they shouldn't be using Linux anyay.

[Marcelo Rodrigues]

Re: Doesn't Mikrotik run on Tile?

"The Cloud Core Router range appears to. Most of the RouterBoard products as well as the CRS line are on MIPS chips though."

Yes, the CCRs are all Tile jobs. They are using some ARM too, on some new products. If I remember correctly, they use a 3.6 kernel, in all product line.

[Jonathon Green]

I was working with uClinux on Blackfin a few years ago for a company developing a domestic picocell product to extend mobile coverage over a home broadband connection, and yes, the absence of an MMU was a PITA...

[John Smith 19]

"the absence of an MMU was a PITA..."

I'll just bet.

I'm thinking of Tannenbaums book on "Mimix" written for an actual 8086 PC with no MMU.

Multi tasking without hardware support.

Nasty.

[Ken Hagan]

Re: "the absence of an MMU was a PITA..."

I think it is often overlooked that Minix wasn't the only such. Real-mode Windows managed transparent swapping of code segments and usable semi-transparent swapping of data as well. It ran on quite a few systems in its day. It wasn't pre-emptive, but that only meant that apps had to be well-behaved and if we are being entirely fair then I have to make the observation that Minix apps had to be well-behaved too, since they all had unrestricted access to the whole of system memory. Similar comments apply to the early Mac operating systems.

Pre-emption (requiring a processor that can restart instructions) and real memory management are certainly both needed if you want to run buggy or badly behaved apps, but systems that require good behaviour are still a lot more useful than systems that can only run a single app. (In the embedded space such "trusting" supervisors are still widespread.)

[Warm Braw]

Re: "the absence of an MMU was a PITA..."

Similar comments apply to the early Mac operating systems

As I recall, data swapping wasn't really even semi-transparent: memory allocation returned the address of an indirect pointer whose location remained constant but whose value would change arbitrarily across system calls as data was moved around memory. Failure to reload pointers from handles after a system call was a frequent source of bugs.

[Ken Hagan]

Re: "the absence of an MMU was a PITA..."

@Warm Braw: that "lock, use, unlock" pattern is exactly what I meant with the phrase semi-transparent. Yes, it required a weensy bit of programmer discipline, but it wasn't actually *hard* to remember.

Of course, in those days, you were expected to have read the documentation and applied a three-digit IQ to the task of programming. Things went downhill when they added "proper" virtual memory and Windows was suddenly open to hordes of Unix programmers who just assumed that their OS would satisfy any malloc() call they cared to write, ever.

[John Brown (no body)]

Re: "the absence of an MMU was a PITA..."

"I think it is often overlooked that Minix wasn't the only such."

Pre-PC days, I used an 8088 (8086?) based multi-user CP/M box which had 4 dumb terminals connected via RS232C ports. There was also Concurrent DOS from Digital Research. It may well be hard to do, but plenty of people have done it.

[Alistair]

Re: "the absence of an MMU was a PITA..."

@John Brown:

Auuuugghhhh!! You are reminding me of one of my *very first* official computer operator roles. It goes far too far back in time ......

The Concurrent DOS system with a nine-track reel-to-reel on the top with 10 terminals. I kicked everyone out of the office at 3:30 on Fridays so I could run the backup. I dropped the tape off with my neighbour (who owned the company) on my way home. (yeah, it was one tape)

[onefang]

Re: "the absence of an MMU was a PITA..."

I recall the Amiga had a multi tasking OS sans MMU.

[Anonymous Coward]

Re: "the absence of an MMU was a PITA..."

> I recall the Amiga had a multi tasking OS sans MMU.

I was just thinking this. It was pre-emptive as well. MMU is by no means a prerequisite to multi-tasking.

[Chemist]

Re: "the absence of an MMU was a PITA..."

"I recall the Amiga had a multi tasking OS sans MMU."

It did but any serious glitch would crash the whole system (Guru Meditation)

[davidp231]

Re: "the absence of an MMU was a PITA..."

"I was just thinking this. It was pre-emptive as well. MMU is by no means a prerequisite to multi-tasking."

It's a pre-req for virtual memory isn't it?

Mac System 6+Multifinder to System 7.5.5 run on the m68k and that definitely lacks a MMU.

[Anonymous Coward]

Re: "the absence of an MMU was a PITA..."

The primary reason I selected the Amiga 1000 was the review in Byte magazine which covered the "how" of its multitasking. Having a solid background in mainframes and having deal with personal computers of the time period (1985), there was no way in Hell I was going to demand anything less. Turns out that a machine designed as a premium games platform may not have been a total success as a game machine, it made a wonderful multitasking machine. However, do recall it was also the design of the custom coprocessors by Jay Miner that lent a serious helping hand. Prior to that, if you wanted to see that level of coprocessor interaction, you had to go look at an IBM mainframe. [There may have been others, I just know the IBM's best.]

I still miss mi Amigas, especially when I have to have extremely overrated specs on a current generation machine just to do what it did out of the box. Thirty years ago.

[onefang]

Re: "the absence of an MMU was a PITA..."

"Turns out that a machine designed as a premium games platform may not have been a total success as a game machine, it made a wonderful multitasking machine."

Even funnier when the IBM PC became known as a games machine.

[John Smith 19]

However,..recall it was also the design of the custom coprocessors by Jay Miner

that lent a serious helping hand.

Indeed.

Looking it up it seems although the Amiga did not have a proper Motorola MMU, it did have shall we say "hardware assisted" memory mangement?

Also it's O/S was not Linux (or a Unix port) but something called "Tripos" which came out of Cambridge University and was written in BCPL, the precursor to C.

The Atari ST, not so hot.

[Gene Cash]

Re: "the absence of an MMU was a PITA..."

> multi-user CP/M box

I worked on an S-100 box running MP/M 8-16, which was not only multi-user CP/M, but utilized a board with an 8088 and a Z-80 on it, to run 8 & 16 bit code.

That was fun. What was not fun was pouring ultra-fine cat litter out of the box every 3 months, because that's what we manufactured.

What was also fun was writing DBase code with a Bengal tiger at my feet, who was a retired circus animal we used for our Mighty Cat brand at trade shows. When you pet a tiger, the fur is so deep your hand goes in halfway to your elbow.

[onefang]

Re: "the absence of an MMU was a PITA..."

"That was fun. What was not fun was pouring ultra-fine cat litter out of the box every 3 months, because that's what we manufactured."

At least it wasn't used cat litter.

Slightly less fun, I used to do sysadmin duties for a clay tile company. All that fine clay dust covering the insides of the computers, and sucking moisture out of the humid sub tropical air, then setting.

[Unicornpiss]

In other IT news..

..Microsoft added 8 more apps that you'll never use and that can't easily be removed to its 'Start' menu, the total update weighing in at only 500MB and taking a mere 1-2 hours to install, and added a "Use middle finger and swipe to reboot" option for tablet users..

[steelpillow]

Re: In other IT news..

"and added a "Use middle finger and swipe to reboot" option for tablet users.."

Shouldn't that be "Extend middle finger and jab vertically upwards to reboot"?

[Anonymous Coward]

Re: In other IT news..

You have to do it three times.

Mr. Torvalds demonstrates: https://youtu.be/_36yNWw_07g?t=10s

[Tom 7]

Re: In other IT news..

Google seem to have taken to making my phone update 11 apps that I dont use every week. I think its because I dont give permission for one of the apps I dont use to do something new so it just updates them every Monday. They are learning from the masters tho.

[Anonymous Coward]

Why do we even bother with Linux...

...when there's Minix and Java ready to go on every Intel chip out there?

[oldcoder]

Re: Why do we even bother with Linux...

Because there is a LOT more non-Intel out there than there are Intel.

There is also the problem that Minix isn't designed for what Linux does...

[John Smith 19]

"...when there's Minix and Java ready to go on every Intel chip out there?"

Wheather or not you asked them to be there.*

*Regardless of wheather they could be shut down or not either.

[Norman Nescio]

amdgpu regressions?

Having found the magic incantations* that allowed me to force the use of the spiffy new amdgpu driver on 4.14.<something> instead of the radeon driver on my laptop, a quick try-out of 4.16 showed me a nice black, unused external display. Sigh.

I would report the issue (which might easily be user ignorance on my part), but the bug-reporting process through Ubuntu is worse than completing a tax-return. No doubt it is made deliberately hard to keep out the riff-raff (like me), but it does mean stuff does go unreported, and even if reported, often unresolved, as I can't do the necessary bisection** to find out which particular patch/update caused the problem.

*GRUB2 kernel boot options in /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="amdgpu.cik_support=1 radeon.cik_support=0"

**I know why this needs to be done, but I don't have a spare test device I can do all the necessary work on, which is frustrating. I guess I need to get slicker at building and booting from a USB key to test different kernel/systemd/driver versions.

[Gene Cash]

Re: amdgpu regressions?

> bug-reporting process through Ubuntu

Really? Debian just asks you to run "reportbug" with the argument of the failing package name.

They got in touch and helped me properly report a regression in the nvidia drivers to nvidia.

I did do some Googling about an ALSA sound issue recently. I discovered the Ubuntu forums are pretty elitist and entitled, at least about sound issues. I thought that sort of thing had gone away. The responses were angry "figure out your own hardware" replies, "read the FAQ", or "use pulseaudio you idiot!"

[Norman Nescio]

Re: amdgpu regressions?

I am slowly coming to the opinion I should extract my digit and move from Ubuntu to Debian, or maybe Arch. I have been consistently impressed with the Arch documentation, whereas the Ubuntu documentation has appeared more Parson's eggish.

[Anonymous Coward]

Re: amdgpu regressions?

> bug-reporting process through Ubuntu

I once reported a bug to Ubuntu. 5 years later, someone looked into it. I never bothered again.