I think most university's are.. and have done for decades.. You should see what research facilities, science labs and industry are running then. There are custom made unix/linux software out there you haven't even heard of and never will as a regular consumer.
I think most university's are..
In Germany? Hell no!
Same thing in Hochschule Augsburg. All the PCs here run Debian. Runs like a charm.
One of our professors demanded to use linux for his course and told the IT to set it up. They setup a VMware with ubuntu and the software we needed, but it was a pain to set it up properly with some hardware then. It was a fun task to keep a bluetooth connection stable when windows decides to kick it every 2 minutes, fun times.
I wish the whole university had linux to work with instead of windows. And it was also in germany.
Linus is already roasting Intel: https://www.spinics.net/lists/kernel/msg2688875.html.
If you can sleep tonight, you don't really understand the problem this class of bugs presents.
But I'm really tired tho
This email is pretty savage too. LOL
Here is the 411 on this:
Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.
Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.
Meltdown breaks the most fundamental isolation between user applications and the operating system. This attack allows a program to access the memory, and thus also the secrets, of other programs and the operating system.
If your computer has a vulnerable processor and runs an unpatched operating system, it is not safe to work with sensitive information without the chance of leaking the information. This applies both to personal computers as well as cloud infrastructure. Luckily, there are software patches against Meltdown.
Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre
Spectre is harder to exploit than Meltdown, but it is also harder to mitigate. However, it is possible to prevent specific known exploits based on Spectre through software patches.
Meltdown breaks the mechanism that keeps applications from accessing arbitrary system memory. Consequently, applications can access system memory. Spectre tricks other applications into accessing arbitrary locations in their memory. Both attacks use side channels to obtain the information from the accessed memory location. For a more technical discussion we refer to the papers (Meltdown and Spectre)
There are patches against Meltdown for Linux (KPTI (formerly KAISER)), Windows, and OS X. There is also work to harden software against future exploitation of Spectre, respectively to patch software after exploitation through Spectre .
Cloud providers which use Intel CPUs and Xen PV as virtualization without having patches applied. Furthermore, cloud providers without real hardware virtualization, relying on containers that share one kernel, such as Docker, LXC, or OpenVZ are affected.
The bug basically melts security boundaries which are normally enforced by the hardware.
The name is based on the root cause, speculative execution. As it is not easy to fix, it will haunt us for quite some time.
The PTI patch (that AMD was saying didn't apply to them) only mitigates Meltdown. Spectre applies to AMD, Intel, and ARM and is not shut down by PTI.
How was it misleading or passive aggressive? It specifically stated what it did not need mitigations against, nothing more nothing less.
I think you got caught up in the hype.
Intel CPUs have a really scary hardware security bug. It is possible to block exploitation of this bug in software (the kernel), but there is a 5-50% performance penalty. AMD CPUs do not have this flaw, and therefore users of AMD CPUs shouldn't have to pay the performance penalty for the software fix. This disables the software fix for AMD CPUs.
Pretty savage commit by AMD. Intel having a bad 2017 and 2018
Whats this mean for someone who doesn't know what this means?
Keep in mind that is an estimation, and an edge case of the estimation.
facebook is the malware
That chuckle vanished.
It takes you to a page that says
Your [Not Linux] machine may be infected
AMD continues to impress me. I mean, they actually deliver. They said there will be open Vulkan driver and did it. They said they will try to improve PSP situation and did it. They didn't give up and in the end had DC DAL merged into Linux 4.15 after nearly half-rewrite.
I won't forget AGESA/PSP and GPU blobs in linux-firmware, but I can say sincerely now: AMD, you're the best. Thank you, developers, for your hard work. Thank you, managers, for actually listening.
Yeah, AMD is really stepping up their game. Makes me want to return to AMD/ATi in a future build.
Direct link (due to phoronix ban): https://www.phoronix.com/scan.php?page=article&item=amd-open-vulkan&num=1
Keep in mind that I may be biased as my PC is all-red now and I track mostly AMD-related stuff. Consult with /sub/linuxhardware before the switch
This man has more integrity than virtually every world leader.
Some wear traffic cone hats.
Not all heroes wear capes
It's a paradox of pride. The people who seek power are also those that would most abuse it and the people who would least likely to seek power are those that would be least likely to abuse it.
It's "easy" to make a distro, so a lot of people do. Some companies/distros have a specific goal in mind, like being great for new users (Ubuntu, Mint), great for servers and corporations (RHEL, CentOS) penetration testing (Kali, BlackArch), making it truly yours (Arch) or anything else. Some of them are just a "reskin" of ther distros, (for example Xubuntu is Ubuntu but with XFCE4 instad of Unity/Gnome). Sometimes they are meant to be a joke (like Hannah Montana Linux).
Besides Linux there is also a bunch of other Unix like systems, like BSD and it's variant, but I'll let someone who knows more talk about them.
Why are there so many different cars? Why are there so many different clothing styles? And so on. Because people like different things and in the Linux world, the barriers to creating your own are relatively low.
Hannah Montana Linux
That's a name I haven't heard in a long, long time.
Linux distros are released single file to hide their numbers.
Linux firmware separation already causing problems
<rant> Some time ago, firmware was disallowed from the Linux kernel source tree. There was already an existing Git repo linux-firmware, and the rules were changed so that all firmware should only go into this tree.
I did think of a problem that could occur, which is that the kernel code and firmware could get out of sync, since there is no proper versioning or branches for the linux-firmware git repo. Arch Linux for example, updates linux-firmware more frequently than other distros.
And I faced this problem today, when Arch Linux decided to use a newer commit of linux-firmware that uses version 34 of the firmware for iwlwifi-8265, but this requires changes in the kernel to work correctly. (See https://bugzilla.kernel.org/show_bug.cgi?id=197591). These changes are not present in any stable version of the Linux kernel including 4.14.2
So, any stable version of the kernel fails to work with version 34 of the iwlwifi-8265 firmware. In the case of my laptop, WiFi is unusable (cannot scan or connect to known WiFi access points).
The separation of linux-firmware into a separate git repo is nice and all, but IMO they should version it using the same version as the kernel, so that this kind of screwup doesn't happen. </rant>
The firmware separation happened years ago. What was removed in the latest release were some leftovers. Most drivers have been working with a separate firmware tree for a long time without problems. And iwlwifi is one of them, the removal of firmware in last release didn't affect your hardware because there was no iwlwifi firmware in it in first place, their firmware has been shipping in the firmware tree for a long time.
There is not any problem with the firmware repository being updated with newer firmware, because newer firmware blobs are usually stored in different files. If you look at the new iwlwifi firmware you mention, it was merged as a completely new file with a "-34" suffix, old v31 files were not removed (in fact there are even older versions) : https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=5a05332d5d... . Because drivers specify which firmware version they support, there is usually not a problem with firmware versions because your driver should ask to load the v31 firmware file even if there is a v34 file available (if it's not doing that, the driver is broken).
Edit: the problem, as seen in the links provided by /u/arsv, is that the driver asks to load the v34 firmware. So Intel apparently merged the code that allows to load v34 firmware, but as they explain in the bugzilla they "forgot" (read: didn't test) to include the code to actually support it. Entirely their fault.
Looks like you’re barking up the wrong tree.
If the Arch maintainers are packaging firmware which doesn’t match the currently packaged kernel, they are doing a bad job.
You cannot blame upstream for mistakes committed downstream.
since there is no proper versioning or branches for the linux-firmware git repo
iwlwifi defines min and max fw version the driver is allowed to load . The driver will try to load fw starting from max and down to min , in this case 34, 33, ..., 22, until it finds one. Looks like they defined max supported version above what the driver actually supports, so it's probably a bug.
Remove iwlwifi-8265-34.ucode and let the driver load the next available version, 31 or whatever you've got there.
 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/inte...  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/inte...
There would still be problems like this even if the firmware were still part of the main tree.
Hopefully they'll rename it to GitVS. Otherwise it'll be confusing on Linux since GVfs already exists.
Nah, they've been made aware of this long ago and they don't seem to give a rats ass about it.
Maybe GNOME can rename theirs to “FileSystem”, they have a penchant for the abuse of generic names as front-facing names of their programs.
You don't have to download the whole repo at once. Instead you dynamically download pieces as you need them. It's mainly meant for large repos.