1: http://www.seagate.com/au/en/support/downloads/item/wireless...
2: http://www.tp-link.com.au/gpl-code.html?model=Archer%20D9
If you want hardware you can tinker with build your own from parts you know work with recent kernels or buy a product specifically marketed at that segment.
Because they don't have a proper QA procedure at the software level, they fear change and have to keep maintaining an in-house snapshot of a archaic ecosystem. They spend and more keeping the obsolete system going, because they have in past years made the cost of upgrading higher and higher.
Eventually they get forced into ground-up rewrites, with all their predictable problems.
I know a ton of embedded company that still have windows 98 or XP machine, because they need them to drive their flash tools or their debugger.
The whole industry stopped updating when the software part tried super hard to sell them Java... and it did not work that well...
In that case, never. Trying to get vendors to open source anything is a hilarious exercise in futility.
https://sfconservancy.org/supporter/ http://gpl-violations.org/helping/
Not really take Broadcom fro example, from https://wiki.archlinux.org/index.php/broadcom_wireless#Histo...
Broadcom has a noted history with its support for Wi-Fi devices regarding GNU/Linux. For a good portion of its initial history, Broadcom devices were either entirely unsupported or required the user to tinker with the firmware. The limited set of wireless devices that were supported were done so by a reverse-engineered driver. The reverse-engineered b43 driver was introduced in the 2.6.24 kernel.
In August 2008, Broadcom released the 802.11 Linux STA driver officially supporting Broadcom wireless devices on GNU/Linux. This is a restrictively licensed driver and it does not work with hidden ESSIDs, but Broadcom promised to work towards a more open approach in the future.
In September 2010, Broadcom released a fully open source driver. The brcm80211 driver was introduced in the 2.6.37 kernel and in the 2.6.39 kernel it was sub-divided into the brcmsmac and brcmfmac drivers.
I hate that this is true. Could anyone explain to me why though? Would it not make life easier for them if they just open sourced their firmware and let other people update/maintain it? (Sorry for the noob question, I haven't looked into this in detail)
But that's just one guy, one company. I believe most companies like the stability of using something old and well proven.
Isn't it the opposite with the kernel, though? Doesn't its stability improve over time? That's at least the feeling I get. I make some embedded "devices" as a hobby (none of it is mass-produced), and I feel like things are better now than they used to be ~3 years ago.
Has anyone used this to calculate how many containers can be packed onto a machine based on historical usage data?
If you want to follow the advancement of Linux graphics stack (while having reasonable graphic performance), AMD is your choice. This is where the exciting new stuff, like Wayland, DRI3 etc. happens. The NVIDIA proprietary driver indeed has amazing performance, but is falling behind on this regard.
AMD's Linux team is in the middle of a big push to modernize the driver and software stack. It seems they consider it a mostly working preliminary version.
You can choose-your-own-adventure with the totally open amdgpu+mesa stack or use the proprietary AMDGPU-PRO. You can follow development of the open source parts on this mailing list:
https://lists.freedesktop.org/archives/amd-gfx/
I do agree with others that NVIDIA is a better choice if you want something that just works and you don't care about proprietary vs. open source.
In terms of stability, the proprietary nvidia drivers are simply the best, and gave me significantly less issues. For my daily workstation I even ended up replacing my (expensive) AMD card for an nvidia one because the desktop environment felt like it was running less than 10 fps, and it triggered me to no end.
Even if AMD gets equal or even better performance than nvidia in gaming environments, I am not willing to compromise the desktop for that.
If you don't mind using the closed-souce nvidia driver, I strongly suggest nvidia.
I bought an nVidia card and didn't have to touch anything and it's completely stable (in the same exact PCI slot).
I might try AMD again in a year or two as I prefer their model of actually supporting and writing open source drivers in contrast to the scummy nVidia whose cards now require a signed firmware that they won't release to the open source community after we got the reverse engineered open source drivers (well, they did release one now for the 9xx series after they released the 10xx series).
http://linrunner.de/en/tlp/docs/tlp-linux-advanced-power-man...
The short of it though is as you suggest, even just installing TLP makes a monumental improvement to battery life.
On my AMD APU laptop, I have been unable to get battery life to be similar to windows.
Also worth noting is that NVME ssd power management is flat out unsupported resulting in additional 3W power draw on DELL XPS 13 pcs out of the 6W that's currently possible with stable power options enabled.
Greased WeaselIt's being reworked into bus1 which is a slim, generic bus implementation. Full dbus can be implemented over it, but it's not forced on people who just want a nice, light bus interface with some security guarantees.