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.
Personally I go the "other" way. Router + WiFi (I use an Airport, but pick your poison), and then the most basic modem possible for the location - this might be a provider-supplied DOCSIS Modem/Router in bridge mode, right now it's a provider-supplied "1 port" ADSL2+ modem/router in bridge mode. With an ADSL setup, you'll probably need to use PPPoE from the router, with a DOCSIS setup, the auth is usually on the MAC address so your router doesn't need to know anything, it just connects via IP to the bridged cable modem.
If the modem ever gives me issues, I'll just replace it with a plain-jane ADSL2+ modem. If the ISP's expand their docsis/fibre network past our new house, I'll just swap the ADSL modem for a DOCSIS modem/router in bridge mode.
This setup has given me the least headaches in every scenario across several houses in both Australia and Thailand. The only hard part really has been trying to express "I want a DOCSIS router that i can turn off the router" in a way that a Thai-speaking technician or my non-technical english&thai speaking wife can all understand.
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...
The Omnia has not shipped yet, but production is starting soon. Their kickstarter was wildly successful.
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/
I'm hoping there's another donation matching campaign at LCA2017 for Conservancy next year - I was able to donate somewhere close to $300 via that last year.
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)
2) FCC prefers SDN radios be blackboxes
3) costs more money to document and support
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.
I guess what they meant was that sticking to old versions gives you a stable target to develop against, not that the resulting product will be stable.
Upgrading to 4.whatever would give you all the improvements, absolutely, but it would also give you all the new bugs, and mean that you have to keep up with all the refactoring that have been done since (and will be done in the future, if you plan to stay up to date).
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.
That means that I usually have around 7-8 hours of battery on my average use, and if I'm in a battery-sensitive environment like a long flight, I can reduce screen brightness and turn off wifi and get up to 14 hours of battery.
Right at this moment I have Fx with 2 windows, 10 tabs each, half-brightness, wifi on, and I'm at 5.78 W, 87% battery with 9h 28m left estimated.
I believe Windows may have even better, and I see my NVMe not dropping to the lowest power saving state, but it's not that bad IMO :)
I do have a Surface pro 4 with a skylake chip in it and even Microsoft appears to have struggled with power management on that chip. The Skylake NUCs have also been plagued by multiple issues. I briefly looked into getting one, but the issues scared me away.
Greased WeaselI do believe that right now you basically have to start dbus using initramfs so that it is ready for use by the time the kernel starts up systemd.
Franky the number of things that they cram into initramfs on a systemd based distro is nauseating.
It'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.