There's a limit to how far you can go with that policy but it does seem that in this case the regression was fairly obvious. As always there's a xkcd about it:
Btw: The quoted changes for MacBooks are slightly inaccurate. MacBook Pro's from 2015 already had working keyboards and touchpads as they have them connected via USB as well. The models which got support now are:
- MacBook 2015
- MacBook 2016
- MacBook 2017
- MacBook Pro 2016
- MacBook Pro 2017
Mind that MacBook Air's and MacBook Pro's from 2018 onward still don't have upstream keyboard and touchpad support.
There has been a lot of progress regarding audio in the past few weeks. Rudimentary audio support is there now and I'm confident we'll see better support soon. Check out https://github.com/Dunedan/mbp-2016-linux/issues/111 for more details.
There's still progress being made, but WireGuard does do a lot of things to/for the in-kernel cryptography stuff. That's been the major holdup for getting it in. There's some that don't like that a new api is being made at all but I believe most are fine with that as long it shares as much internally as possible with the existing code so that there's not two copies of everything. A lot of that has been done last I heard but it wasn't quite ready yet for mainlining in that fashion. I suspect we'll see another RFC for it in the 5.4 merge window and maybe finally some traction at getting it into staging or all the way in.
EDIT: see sibling comment about wireguard and 5.4, apparently not slated for it this time but maybe 5.5.
Last patch set I remember seeing was v9 submitted to the mailing list in March. There was some feedback regarding the new zinc crypto interface and replacement crypto implementations. Jason indicated he would address them for the next patch submission which I don't believe has been made yet.
OP/submitter signed up a month ago and has spent the past week spamming nothing but links to his own splog, which uses old linuxjounal material for 99.9% of its content.
With this he has simply copied an article from Omgubuntu and spammed it via his splog, where he even puts his own name on it.
The link should be changed to the correct Omgubuntu link to credit original and up to date content and not lazy copy and paste spammers.
I for one am excited that 5.3 potentially includes a bug fix for the random hard freezes I see ~daily on my laptop with a Baytrail cpu [1].
Had sort of given up on it ever being resolved, but sounds like a patch got into 5.3 that may fix it. Installed 5.3-rc5 last night. Guess I'll wait and see if it actually resolves the issue.
Installed Ubuntu Mate 19.10 daily 5 days ago on asus t100ta (Atom) and have had absolutely no issues. Added bootia32 to liveusb as is the norm with this machine.Still no camera, but no big deal for me. Everything else works perfect. No c-state freezes and no workarounds needed. 5.3 seems to have fixed the baytrail issues as advertised.
If you game on Linux, note that the 5.3 upgrade DualShock controllers. A recent systemd upgrade also broke some udev rules for controllers. That is easier to fix though:
does anybody know when Wireguard is going to be merged? can it be done before the release that will be deployed in Ubuntu 20.04 next April or is it too late?
In the Kernel, if you're not running the very specific version of Ubuntu they compiled you still need a ton of custom packages from mesa-git and others. I think we're still a few months from stable on all packages and then further months from those packages making it into distros.
It also means that everything either works or doesn't work.
A dependency tracking system with mix & match of versions of subcomponents of the kernel that either work together or not looks like a nightmare to me.
Hurd's changelist looks similar, because just since it's a microkernel doesn't mean you don't want the user space parts colocated in the source tree.
Additionally, pretty much all microkernels that support GPUs (which are very few) have about the same in kernel drivers as monolithic kernels since GPUs have their own MMUs and managing the MMU is about the only thing either wants to do in kernel space.
No - a single source tree means that it contains all that. A microkernel could easily have its source tree set up in a similar way (and there are many reasons one might want to).
[+] [-] thestoicattack|6 years ago|reply
[+] [-] duckerude|6 years ago|reply
[+] [-] pedrocr|6 years ago|reply
https://xkcd.com/1172/
[+] [-] new_realist|6 years ago|reply
[+] [-] Topgamer7|6 years ago|reply
[+] [-] dev_dull|6 years ago|reply
[+] [-] djhworld|6 years ago|reply
Anyone know if the audio for >=2016 era macbooks will ever be made to work? https://github.com/Dunedan/mbp-2016-linux
[+] [-] Dunedan|6 years ago|reply
- MacBook 2015
- MacBook 2016
- MacBook 2017
- MacBook Pro 2016
- MacBook Pro 2017
Mind that MacBook Air's and MacBook Pro's from 2018 onward still don't have upstream keyboard and touchpad support.
[+] [-] Dunedan|6 years ago|reply
[+] [-] baybal2|6 years ago|reply
1. GVE host will never see the light of the day
2. Never be used outside of Google's DCs
3. Hardware that backs its is very likely of Broadcoms origin, with their virtualisation API.
4. It made it! Unlike dozens of attempts by other companies to do the same for their proprietary in-DC hardware. How one does it?
[+] [-] swrobel|6 years ago|reply
[+] [-] simcop2387|6 years ago|reply
EDIT: see sibling comment about wireguard and 5.4, apparently not slated for it this time but maybe 5.5.
[+] [-] NullPrefix|6 years ago|reply
[+] [-] geophertz|6 years ago|reply
https://www.phoronix.com/scan.php?page=news_item&px=WireGuar...
[+] [-] tssva|6 years ago|reply
[+] [-] l1n|6 years ago|reply
[+] [-] green0|6 years ago|reply
With this he has simply copied an article from Omgubuntu and spammed it via his splog, where he even puts his own name on it.
The link should be changed to the correct Omgubuntu link to credit original and up to date content and not lazy copy and paste spammers.
[+] [-] squeezingswirls|6 years ago|reply
[+] [-] war1025|6 years ago|reply
Had sort of given up on it ever being resolved, but sounds like a patch got into 5.3 that may fix it. Installed 5.3-rc5 last night. Guess I'll wait and see if it actually resolves the issue.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=109051
[+] [-] qidon|6 years ago|reply
[+] [-] captn3m0|6 years ago|reply
[+] [-] trpc|6 years ago|reply
[+] [-] geophertz|6 years ago|reply
Wireguard won't be in before 5.5.
5.5 should release in early february 2020 so it might be in Ubuntu 20.04.
[+] [-] TrueDuality|6 years ago|reply
[+] [-] shmerl|6 years ago|reply
[+] [-] wronglebowski|6 years ago|reply
[+] [-] cptskippy|6 years ago|reply
[+] [-] dreamcompiler|6 years ago|reply
How is IPv4 address availability up to the Linux kernel?
[+] [-] dtparr|6 years ago|reply
https://hub.packtpub.com/linux-kernel-announces-a-patch-to-a...
[+] [-] denormalfloat|6 years ago|reply
[+] [-] squeezingswirls|6 years ago|reply
[+] [-] dang|6 years ago|reply
[+] [-] cestith|6 years ago|reply
Paragraph 6, s/Chromebook harder/Chromebook hardware/
Spellcheck is not a proofreader.
[+] [-] Scuds|6 years ago|reply
[+] [-] aprdm|6 years ago|reply
A dependency tracking system with mix & match of versions of subcomponents of the kernel that either work together or not looks like a nightmare to me.
[+] [-] monocasa|6 years ago|reply
Additionally, pretty much all microkernels that support GPUs (which are very few) have about the same in kernel drivers as monolithic kernels since GPUs have their own MMUs and managing the MMU is about the only thing either wants to do in kernel space.
[+] [-] ris|6 years ago|reply