FreeBSD Is Pursuing A Compatibility Layer To Make It Easier To Run Linux DRM Drivers

[pal666]

Nouveau's dysfunctionality running on GTX 660 Ti.

what kind of dysfunctionality?

[pal666]

If you would look into FreeBSD's Nvidia "blob"-driver, you would see it's really modified-for-FreeBSD Linux driver working over Linux ABI

if you would look into linux's nvidia blob-driver, you would see it's really windows driver with tiny wrapper

[SystemCrasher]

If you would look into FreeBSD's Nvidia "blob"-driver,

That's what I call unexciting offer.

you would see it's really modified-for-FreeBSD Linux driver working over Linux ABI. It's not like there is alternative to it in Linux either, as long as you need to use 3D. Nouveau is fine for 2D. You use what you have.

I'm not happy on how "openness" & "freedom" "proponents" are advertising blobs while attacking opensource software. That's what I call double standards. Nouveau actually does 3D and if you failed to notice, it is quite featured (see mesamatrix.net). It would do 3D, with the only limitation it going to be quite slow when it comes to complicated scenes. Even then it going to be much faster compared to software rendering on top of software rendering on top of 2D.

Same issue with plenty of hardware. You could hide whole dedicated embedded operating system into EEPROMs of some of the Intels WLAN cards. Compare those against EEPROM sizes of Atheros cards for example.

Intel has got microprocessor in their cards. It got nothing to do with "EEPROM", firmware is RAM code image for on-board processor. Calling it "EEPROM" is silly, it got nothing to do with Electricaly Eraseable PROMs. All atheros up to (and including) .N ICs are just a bunch of HW automations, eeprom is only needed to store initial state of hardware blocks and board properties, like gain coefficients and somesuch, so board stays within regulatory limits and driver knows what particular board could do. In this case it could be actual EEPROM IC attached to Atheros IC, on power up hardware automation sequences reads and loads registers. It can't do arbitrary things, just loading registers. So atheros is "blob-free": at very most driver touches some registers and large blocks of registers meant to be written after powerup were known as "initvals". The key difference is: .N atheros lacks CPU and can't load and exec turing complete code, to the best of my knowledge (except usb things like 9271, where firmware is opensource). Yet, .AC ICs are coming with huge blob and own CPU. Well, it is qualcomm, not atheros anymore. So you had to expect it. Qualcomm is known for questionable backdoor-like designs for ages. So ath10k and Intel wireless are more or less equally non-trustworthy and even opensource driver wouldn't fully correct that due to huge updateable firmware. That's how one could easily get UNtrusted (or even Backdoored) Computing.

Same appears to be case for Intel Linux wlan drivers, checked a few - binary blob, Readme and License.

These blobs are bad things either. However, they are fundamentally different issue since they are running on entirely different CPU & memory. Foreign kernel module is immediately "taints" kernel, so you never know who has corrupted your RAM and why. In Linux it means devs wouldn't support you at all, if you're usnig proprietary drivers, go fucking handle all bugs yourself. I really like this policy, that's how opensource project could strongly discourage blob kernel modules. Those who ABSOLUTELY need it would still using it, but it raises bar and over time most vendors just gave up on trying to supply blobs for Linux and guess what? They've gone open.

This said, to confine e.g. PCI(-E) device one may really want IOMMU on their side. If one can't afford IOMMU (I guess BSDs are bad at it, and only recent hardware implements it), updateable firmware in PCI-E device is an issue, since device could issue "unexpected" memory accesses, hijacking system at its firmware's discretion and firmware could be updated, to deal with recent OS versions. Uhm, yea, who would like to have "engineering login" in their PCI device? Especially networking one.

Also OpenSUSE is using Nouveau by default. One I always have to switch for binary driver since Nouveau's dysfunctionality running on GTX 660 Ti.

Still, speaking for myself I consider Nvidia policy a major disadvantage and like a middle finger to anyone who cares of opensource & freedoms it brings. Basically, it brings one to the point where Windows has left off. Hardly something exciting. So I fail to get idea of BSD users, who are praising BSD freedoms yet using some hostile blobs like utter consumers. Looks pretty much like double-standards and it smells like these "freedom lovers" are actually proprietary in their very core.

[SystemCrasher]

I can swear I've posted answer to aht0 but it seems forum has swallowed it. No idea why. Maybe "unapproved" random moderation strikes back, or something. Damn, if someone wants showcase of crappy proprietary software nobody could fix, vBulletin would do, any day! Loads of bells and whistles while utterly failing basic core operations and nobody could fix it for years. Perfect showcase of proprietary software. I mean I would have hard time to remember opensource forum software performing worse than that.

[starshipeleven]

I can swear I've posted answer to aht0 but it seems forum has swallowed it. No idea why. Maybe "unapproved" random moderation strikes back, or something. Damn, if someone wants showcase of crappy proprietary software nobody could fix, vBulletin would do, any day! Loads of bells and whistles while utterly failing basic core operations and nobody could fix it for years. Perfect showcase of proprietary software. I mean I would have hard time to remember opensource forum software performing worse than that.

*decades.
vBullettin has been crap for decades. I remember some fun sql injections it had 5+ years ago (and it seems to get some even recently).
I know a team that basically "stole servers" with that.
When pentesting to convince a (big) customer that his setup was crap.
Was scary tho.

I understand migration is a hassle for Micheael, but this forum's infrastructure only thing are good looks.

[aht0]

Intel has got microprocessor in their cards. It got nothing to do with "EEPROM", firmware is RAM code image for on-board processor. Calling it "EEPROM" is silly, it got nothing to do with Electricaly Eraseable PROMs. All atheros up to (and including) .N ICs are just a bunch of HW automations, eeprom is only needed to store initial state of hardware blocks and board properties, like gain coefficients and somesuch, so board stays within regulatory limits and driver knows what particular board could do. In this case it could be actual EEPROM IC attached to Atheros IC, on power up hardware automation sequences reads and loads registers. It can't do arbitrary things, just loading registers. So atheros is "blob-free": at very most driver touches some registers and large blocks of registers meant to be written after powerup were known as "initvals". The key difference is: .N atheros lacks CPU and can't load and exec turing complete code, to the best of my knowledge (except usb things like 9271, where firmware is opensource). Yet, .AC ICs are coming with huge blob and own CPU. Well, it is qualcomm, not atheros anymore. So you had to expect it. Qualcomm is known for questionable backdoor-like designs for ages. So ath10k and Intel wireless are more or less equally non-trustworthy and even opensource driver wouldn't fully correct that due to huge updateable firmware. That's how one could easily get UNtrusted (or even Backdoored) Computing.

Yeah, I'm actually aware of it. Question, why does Intel put them even on fairly slow cards that would not affect your PC's CPU noticeably? It's not needed for ABG and not really even for N standard. Granted, AC cards need dedicated on-board processing, running wlan over CPU @AC speeds might bite off a sizable chunk from CPU's performance.

Atheros 9k eeproms contain MAC address, values for power, regdomain value, which band is allowed (separate values for client and AP mode bands) etc.. Older cards have software-writable EEPROMs, slightly newer ones (AR94xx/95xx) have one-time-writable EEPROM and you would need to go for soldering to change them. I've tinkered enough with those cards. You dump the content, mod certain values using hex editor and put new content back in. Or new chip. Voila, you can suddenly create 5Ghz AP (by default only 5Ghz client mode allowed in AR9280/x). Or mod the "generic" card to be acceptable for some OEM machine (like Dell, HP or Apple).

These blobs are bad things either. However, they are fundamentally different issue since they are running on entirely different CPU & memory. Foreign kernel module is immediately "taints" kernel, so you never know who has corrupted your RAM and why. In Linux it means devs wouldn't support you at all, if you're usnig proprietary drivers, go fucking handle all bugs yourself. I really like this policy, that's how opensource project could strongly discourage blob kernel modules. Those who ABSOLUTELY need it would still using it, but it raises bar and over time most vendors just gave up on trying to supply blobs for Linux and guess what? They've gone open.

a) some unknown OS-like entity running separately from your system as embedded on a network device. You have little or no contol over what it's been sending into Internet and no clue what happens inside it. It's pretty much identical situation and actually somewhat worse with modern smartphones built-in modem devices. Nevertheless, I think you are using some sort of smartphone. Regardless that it's modem may have ability to bypass security of the phone's OS itself and access file systems inside your phone without you knowing it. There are only limited number of smartphones with good modem isolation.

b) binary blob running inside your OS but on non-network device like graphics card, using kernel module built specifically for your OS, using sources present in your system. From stability-standpoint I'd say such module is pretty 'effin stable. Since hardware makers driver developers get paid for their work, I would trust them more than some random hackers..

I am not sure your vaunted free driver is any better from point of view of security either. Considering quality of code in Linux (new features are more so much more important than quality) that "open driver" could (and most likely is to certain degree) full of security holes like Swiss cheese. Binary driver might be even safer to use.

In the end, I'd say binary driver is acceptable and take b. I can expect professionalism from Nvidia's programmers.

Still, speaking for myself I consider Nvidia policy a major disadvantage and like a middle finger to anyone who cares of opensource & freedoms it brings. Basically, it brings one to the point where Windows has left off. Hardly something exciting.

Nvidia is business first, not charity. I am very grateful that they even bother releasing graphics drivers for non-relevant (you can't call these anything else considering few percents of their market share) desktop OSes like Linux/BSD/Solaris. If Nvidia wanted it, it could kill off Nouveau and drop driver support for anything besides Windows and OSX. And give serious blow to Enterprise Linux Desktops in passing. Without Nvidia itself taking noticeable financial hit. So, they are actually pretty decent but it's not enough for your ideology.. You need MORE.

So I fail to get idea of BSD users, who are praising BSD freedoms yet using some hostile blobs like utter consumers. Looks pretty much like double-standards and it smells like these "freedom lovers" are actually proprietary in their very core.

BSD freedom is freedom for user and developer alike. GPL notion of "freedom" is freedom for user but not for developer, it's far more restrictive.

Your notion that all blobs are "hostile" shows that you are presuming hostile intent without slightest proof. It describes schizophrenic. Wish to protect ones business secrets is also "hostile intent"? Have you ever heard of industrial espionage? It's very real threat for a high-tech corporation, especially for one that is dominating the market.

I honor the free will of "creator" of some "product". I do not run to make overall demands based on some notion what I think is "right" in my eyes. Such open source fanatics are in my mind equal to the far-right extremists, extreme liberals, communists and so forth. Shortly, bunch of individuals who have idealistic notions how world should work, start making various demands based on their ideas regardless of the fact that other people may have different view to the world. So convinced that their intentions are best for everyone... argh

It's mentality. Everyone that do not follow YOUR ideals are "bad" and to be denounced/repressed. This is the very exact thing you are all the time trying to do here. Propaganda how Your "Thing" is GOOD, everything different is BAD. bla-bla-bla... You do not respect or accept other people's freedom for CHOOSING what they want to use and how. You have your notion how it should be done and you are hell-bent on it. It's mentality akin to fasc!sm.

Btw, there is not a single blob in OpenBSD. That has not stopped you from bashing it for NOT supporting Nvidia. What did you say about double-standards? Linux kernel (except Linux-Libre) in comparison to FreeBSD is full of blobs. I counted in excess of 100 binary blobs in 4.6 source I downloaded from kernel.org. Fail to grasp the logic of your outburst.

if you would look into linux's nvidia blob-driver, you would see it's really windows driver with tiny wrapper

Care to expand on it? I went and downloaded 361.41 from Nvidia's site (Linux x64 and FreeBSD x64) and 361.42 for Windows 10 x64. 361.41 did not seem to exist for Windows.

Unpacked them all and compared them. I could not find single file in FreeBSD driver that would have remotely looked like "Windows driver with a tiny wrapper".

There were 21 binary modules (.so) in FreeBSD driver's /obj/linux folder that were meant to be used by Linux ABI. /obj main folder itself contained 20 binary modules named by the same pattern obviously meant to be used by FreeBSD directly. There were also 2 files that were probably driver blobs, /src/nvidia/nv-kernel.o, size roughly 13Mbytes (everything else in that folder were source files) and /src/nvidia-modeset/nv-modeset-kernel.o which was smallish, ~900Kbytes. Nothing else, besides ton of source files, Makefile's and such.
By the way, both were in ELF format. Never heard of Windows using ELF.

So, I would conclude that it's a driver created specifically for FreeBSD with the added Linux compatibility layer functionality added on top of it like septianix on second page told us.

what kind of dysfunctionality?

3D acceleration does not work reliably. Sometimes even 2D flickers like ****. Full binary driver works without hitch and there is that.

[SystemCrasher]

Yeah, I'm actually aware of it. Question, why does Intel put them even on fairly slow cards that would not affect your PC's CPU noticeably?

Intel got long story of (ab)using their HW to dictate others what they could or should do. IIRC Intel has refused to implement e.g. monitor modes for a while and it made life of networking people considerably harder. It haven't prevented e.g. wi-fi hacking since other vendors implemented all modes. So the only achievement was alienating technically savvy people and ensuring Intel things are inherently not suitable for advanced wireless setups like e.g. trying some advanced mesh using non-standard signalling and somesuch. Basically, Intel's wireless adapters are most locked down and troublesome things of everything one could get. If one wants just client mode, fine. But everything beyond that could be major issue as far as I know. I've never seen Intel adapters in advanced use cases like APs or mesh networking.

It's not needed for ABG and not really even for N standard. Granted, AC cards need dedicated on-board processing, running wlan over CPU @AC speeds might bite off a sizable chunk from CPU's performance.

Sounds like yet another stupid excuse to feed everyone with dubious blobwares. Whatever, main system CPUs are usually far more powerful than these small cpus running blobs. So I would take such reasoning with a truckload of salt.

Atheros 9k eeproms contain MAC address, values for power, regdomain value, which band is allowed (separate values for client and AP mode bands) etc.. Older cards have software-writable EEPROMs, slightly newer ones (AR94xx/95xx) have one-time-writable EEPROM and you would need to go for soldering to change them.

I've got PDFs on some of ath9k things, giving exact details about everything. Sometimes googling is funny . These PDFs give a good idea how this works. As far as I've understood, since certain HW, EEPROM itself could be programmed with values to prevent reading, writing or both on certain EEPROM regions. So it depends on how these values are programmed. As far as I understand it is possible to write EEPROM usnig HW itself and then demand EEPROM lockout by writing appropriate EEPROM bytes. Oldest HW (handled by ath5k in Linux) had no these features, so their EEPROM is always writeable regardless of how it being programmed.

I've tinkered enough with those cards. You dump the content, mod certain values using hex editor and put new content back in. Or new chip. Voila, you can suddenly create 5Ghz AP (by default only 5Ghz client mode allowed in AR9280/x). Or mod the "generic" card to be acceptable for some OEM machine (like Dell, HP or Apple).

I do not need to fiddle with EEPROM, since I could patch ath9k and I did it a bit, exploring some fancy things ath9k could do .

a) some unknown OS-like entity running separately from your system as embedded on a network device. You have little or no contol over what it's been sending into Internet and no clue what happens inside it. It's pretty much identical situation and actually somewhat worse with modern smartphones built-in modem devices. Nevertheless, I think you are using some sort of smartphone. Regardless that it's modem may have ability to bypass security of the phone's OS itself and access file systems inside your phone without you knowing it. There are only limited number of smartphones with good modem isolation.

I use Nokia N900, its modem runs on entirely different CPU. It lacks access to the rest of system. There're means to turn it off if I do not want it. I have quite good understanding of microprocessor architectures, so if someone thinks they could pwn me in arbitrary manner, I have different idea, using my knowledge for my own good :P. But yeah, cell network haves idea about rough location and so on. Then both modem, ISP and others could fiddle with traffic in arbitrary ways, so It have to be considered. One can't rely their traffic passing through net unchanged. Cell modem on its own isn't exception. Backdoored architectures? Feel free to use them, but I'm out. I'm picky, sorry :P.

b) binary blob running inside your OS but on non-network device like graphics card, using kernel module built specifically for your OS, using sources present in your system. From stability-standpoint I'd say such module is pretty 'effin stable. Since hardware makers driver developers get paid for their work, I would trust them more than some random hackers..

From practical standpoint, GPU is confined by IOMMU, as well as other PCI(-E) devices. Secondary CPUs on other intefaces are even less harmful. So their options to hijack system are limited. But still it have to be considered.

I am not sure your vaunted free driver is any better from point of view of security either. Considering quality of code in Linux (new features are more so much more important than quality) that "open driver" could (and most likely is to certain degree) full of security holes like Swiss cheese. Binary driver might be even safer to use.

Whatever, I do not want foreign blobs running on primary system cpu in my systems. This leads to load of nasty issues and I've fed up with these since windows ages. There is no going back, so advertising me blob drivers is futile. It only warrants loss of respect and considering one some stupid consumer.

In the end, I'd say binary driver is acceptable and take b. I can expect professionalism from Nvidia's programmers.

I do not need or want professional pwnzors and troublemakers in my systems. I enjoy the way Linux being developed, that's what I call really inspiring. Blobs interfere with it. Tainted kernels are no-go in Linux. Furthermore, Nvidia is hardly welcome in Linux due to their uncooperative nature. Then I do not really get why I'm supposed to respect those praising troublemaking corporations. IMHO such persons do not respect self, so I do not have to respect them either.

Nvidia is business first, not charity. I am very grateful that they even bother releasing graphics drivers for non-relevant (you can't call these anything else considering few percents of their market share) desktop OSes like Linux/BSD/Solaris. If Nvidia wanted it, it could kill off Nouveau and drop driver support for anything besides Windows and OSX.

I would not care. I do not have their GPUs. Yet they can't completely kill nouveau, it has appeared without nvidia support, to begin with. Furthermore, Linux on its own wouldn't lose anything. It is nvidia and their customers who have something to lose. Linux gains very little from these useless consumers, and I guess most Linux devs are smart enough not to use nvidia, at least because running tainted kernel is a no-go when it comes to anythnig related to kernel development. Anyone running such kernel going to be redirected to nvidia to handle all their bugs, etc. That's how Linux devs deal with proprietary wrenches. They are unwelcome. I warmly welcome such policy. Maybe it isn't best for consumers like you, but keeps overall ecosystem around kernel development sane.

And give serious blow to Enterprise Linux Desktops in passing. Without Nvidia itself taking noticeable financial hit.

Just take a look into Top 500 of supercomputers and which OS these are using. I'm pretty sure, if nvidia would give up HPC, other vendors will be more than happy to take it over

So, they are actually pretty decent but it's not enough for your ideology.. You need MORE.

They are stupid and playing with fire, showing middle fingers to OS which holds significant part of their business. I think it is shortsighted a bit and could eventually pay for itself. Uhm, yeah, I remember AT&T, lawsuit and ubuntu . Then if someone is ok with being third-rate corporate footpads like BSDs, fine, but I think it could be a bit better than that.

BSD freedom is freedom for user and developer alike.

I've noticed, thanks, so somehow I can't get source for some small device and hack on it. Because each and every proprietary wrench has (ab)used their freedom to show middle finger everyone around. I do not need freedom to receive so many fucks in my face, thanks.

GPL notion of "freedom" is freedom for user but not for developer, it's far more restrictive.

GPL just keeps everyone equal. I think it is perfectly fair, especially as the way to interfact between devs and somesuch. Especially in large distributed project where nobody could claim they wrote all the code, so I do not get why they should be able to take over what they haven't even created, in first place.

Your notion that all blobs are "hostile" shows that you are presuming hostile intent without slightest proof.

I've seen enough of troublesome behavior from blobs, this is more than enough proof for me. When someone does not shows their source, I would question their motivation and since e.g. RH does BILLIONS without closing source, I wouldn't take "business" as excuse, sorry. Defective/troublesome business models hurting others are IMHO poor excuse.

It describes schizophrenic. Wish to protect ones business secrets is also "hostile intent"? Have you ever heard of industrial espionage? It's very real threat for a high-tech corporation, especially for one that is dominating the market.

Somehow these secrets tend to hurt others, be it inability to fix bugs, vendor locking or treacherous/undesirable/malicious activity. So speaking for myself, I had enough of proprietary software treachery and consequences of vendor locks to start to actively dislike proprietary software. If someone is not happy with such treatment, go look into the mirror first. Customers have numerous reasons to dislike proprietary software and whole rise of opensource wouldn't be possible without major demand to replace proprietary software with something better than that. Yeah, bitching about your ultimate author rights haves its price: at the end of day, proprietary scums mistreating others could eventually figure out quite few people want to be treated like this. But some of them are clearly getting the idea way too late, which warrants some funny showcases . Interestingly most skilled and smart humans around are smart enough to get idea and get over stupid and counterproductive greed-induced bitching.

I honor the free will of "creator" of some "product". I do not run to make overall demands based on some notion what I think is "right" in my eyes. Such open source fanatics are in my mind equal to the far-right extremists, extreme liberals, communists and so forth. Shortly, bunch of individuals who have idealistic notions how world should work, start making various demands based on their ideas regardless of the fact that other people may have different view to the world. So convinced that their intentions are best for everyone... argh

I also decided to honor will of authors. I behave exactly like authors have demanded: if I'm not agree, I do not use their programs. So, virtually no proprietary programs left on my computers. Just because I'm not agree with their fucking EULAs. Isn't it funny? Yeah, you could get your wish granted and let's see if you're happy with it.

It's mentality. Everyone that do not follow YOUR ideals are "bad" and to be denounced/repressed. This is the very exact thing you are all the time trying to do here. Propaganda how Your "Thing" is GOOD, everything different is BAD. bla-bla-bla... You do not respect or accept other people's freedom for CHOOSING what they want to use and how. You have your notion how it should be done and you are hell-bent on it. It's mentality akin to fasc!sm.

Somehow, proprietary authors also consider self like gods, who think they could pwn everyone, post arbitrary demands and get with it. Which isn't too far from fasc!sm or other kinds of draconian dictatorship either. But there was little catch. Customers aren't exactly fond of this kind of attitude. So e.g. proprietary BSDs in embedded died really quickly in favor of Linux. Yes, BSDs were here before Linux, but it haven't worked out.

Btw, there is not a single blob in OpenBSD. That has not stopped you from bashing it for NOT supporting Nvidia.

Nouveau on its own is opensource, but it seems BSD users perfer to hope nvidia will be kind enough. Then, it is really interesting idea to claim you're blob-free while booting off HDD running huge blob firmware, using blobbed BIOS/UEFI and totally disregarding running Intel Management Engine. Sure, formally it is fine, but from practical standpoint it isn't big achievement, because nasty blobs like ME are resident and running. And when achieved result grossly differs from what has been advertised, I call it "marketing BS". Or in best case it could be just ignorance/incompetence, so typical for BSD fans & overall project management. FSF is also could take similar blame, but there is Libreboot, so they at least honestly acknowledge problem rather than trying to downplay it or silently ignore it. Which is more fair approach to my taste. Interestingly I tend to agree OpenBSD users Nvidia is a really bad vendor. But I'm not sure we'll agree why exactly .

What did you say about double-standards? Linux kernel (except Linux-Libre) in comparison to FreeBSD is full of blobs. I counted in excess of 100 binary blobs in 4.6 source I downloaded from kernel.org. Fail to grasp the logic of your outburst.

Double standards is when you promise blob-free system, but it turns it is not a case. Just trying to pretend BIOS isn't your responsibility is childish. When SMI# handler knocks your blob-free OS out of the way, there is nothing blob-free OS could do. So it seems it lacks complete control on what's going on. Goal is not achieved. FAIL. Yeah, I value opensource for predictable behavior and lack of unexpected proprietary-style surprises. FSF is more fair, they've got Libreboot, so they at least acknowledge the problem, rather than feeding me up with stupid marketing BS. E.g. my devices are actually blob-free. I mean no blobs would kick my code out of system CPU. I have tight control over boot sequence, my code takes over early and no unknown blobs are called since this point of time. There're no major firmwares, except maybe SD-card, which is one of easiest things to get it to behave and it could also be say, raw NAND or SPI instead, so it is could be totally blob-free to the best of my knowledge. That's how I could accept blames if my device misbehaves. I think Linux devs got really reasonable point refusing to investigate bugs in tainted kernels running unknown blobs.

[aht0]

I've never seen Intel adapters in advanced use cases like APs or mesh networking.

Atheros, Ralink, Marvell (some of them), Lucent Hermes/Intersil Prism WLAN cards should have capability to do AP. Intel cards cannot. For mesh networking Atheros, Marvell, Ralink (some USB 802.11n models?). Also Intel cannot.

Sounds like yet another stupid excuse to feed everyone with dubious blobwares. Whatever, main system CPUs are usually far more powerful than these small cpus running blobs. So I would take such reasoning with a truckload of salt.

consider laptop CPUs for example. Mostly quite limited performance, except for enthusiast models. But laptops are the primary target machines where AC NICs are most likely going to be used. Onboard processing is far more efficient than NIC sending all it's I/O all the way to the CPU and then waiting it's return. Efficiency goes up as transfer speeds increase.

I've got PDFs on some of ath9k things, giving exact details about everything. Sometimes googling is funny . These PDFs give a good idea how this works. As far as I've understood, since certain HW, EEPROM itself could be programmed with values to prevent reading, writing or both on certain EEPROM regions. So it depends on how these values are programmed. As far as I understand it is possible to write EEPROM usnig HW itself and then demand EEPROM lockout by writing appropriate EEPROM bytes. Oldest HW (handled by ath5k in Linux) had no these features, so their EEPROM is always writeable regardless of how it being programmed.

Nothing stops you from reading EPROM/EEPROM chips once you soldered the chip out from the circuit and read it externally using programmer.

I do not need to fiddle with EEPROM, since I could patch ath9k and I did it a bit, exploring some fancy things ath9k could do .

Do it once and you never have to worry about patching it. Otherwise you'd have to patch it over and over again as you reinstall OS or install new kernels..

I use Nokia N900, its modem runs on entirely different CPU. It lacks access to the rest of system. There're means to turn it off if I do not want it. I have quite good understanding of microprocessor architectures, so if someone thinks they could pwn me in arbitrary manner, I have different idea, using my knowledge for my own good :P. But yeah, cell network haves idea about rough location and so on. Then both modem, ISP and others could fiddle with traffic in arbitrary ways, so It have to be considered. One can't rely their traffic passing through net unchanged. Cell modem on its own isn't exception. Backdoored architectures? Feel free to use them, but I'm out. I'm picky, sorry :P.

I sort of expected "I am using Samsung S3 running Replicant 4.2"

Whatever, I do not want foreign blobs running on primary system cpu in my systems. This leads to load of nasty issues and I've fed up with these since windows ages. There is no going back, so advertising me blob drivers is futile. It only warrants loss of respect and considering one some stupid consumer.

what about blobs in N900? 3D accel, GPS, Camera, WLAN, BT, Radio - are usually ones lacking OSS drivers for phones. Mostly binaries

I do not need or want professional pwnzors and troublemakers in my systems. I enjoy the way Linux being developed, that's what I call really inspiring. Blobs interfere with it. Tainted kernels are no-go in Linux. Furthermore, Nvidia is hardly welcome in Linux due to their uncooperative nature. Then I do not really get why I'm supposed to respect those praising troublemaking corporations. IMHO such persons do not respect self, so I do not have to respect them either.

Lol, Nvidia should drop supporting linux PC market for the next 5 years. Including locking users out of 3rd party drivers. Just to show what "uncooperative nature" looks like :P You'd see desktop-linux usage plummeting down and since majority of users have Nvidia in their machines. Lots and lots of Linux users have dual-boot systems and are using Windows as well. You, see it's reason Linux needed LiLo and GRUB. To boot into multiple OSes. BSD's have never had real need for such multiple-boot capability though you can chainload Windows trough FreeBSD's native boot loader if you wish to.

I would not care. I do not have their GPUs. Yet they can't completely kill nouveau, it has appeared without nvidia support, to begin with. Furthermore, Linux on its own wouldn't lose anything. It is nvidia and their customers who have something to lose. Linux gains very little from these useless consumers, and I guess most Linux devs are smart enough not to use nvidia, at least because running tainted kernel is a no-go when it comes to anythnig related to kernel development. Anyone running such kernel going to be redirected to nvidia to handle all their bugs, etc. That's how Linux devs deal with proprietary wrenches. They are unwelcome. I warmly welcome such policy. Maybe it isn't best for consumers like you, but keeps overall ecosystem around kernel development sane.

Oh, Nvidia could. Lock out unsigned 3rd party drivers, no releasing of binary drivers.. Welcome back to 1999 when getting GPU to work on Linux was pain in the butt.

Nvidia and it's customers have a LOT to lose from niche desktop-OS /sarcasm.

AMD could be bankrupt in next 2 years. It's already known that Polaris can't beat Pascal in performance. AMD is talking mostly about energy efficiency. If Zen should also fail, AMD is done. Preliminary articles promise performance akin to Intel's faster CPU's but not exceeding them.

Just take a look into Top 500 of supercomputers and which OS these are using. I'm pretty sure, if nvidia would give up HPC, other vendors will be more than happy to take it over

Supercomputers or super-clusters of disctinct "component" computers? Put Linux on 32-way hardware and see it fail. Hell, it's showing it's failures on PC right now, just watch the massive uproar about linux scheduler issues in net. "decade of wasted cores"

They are stupid and playing with fire, showing middle fingers to OS which holds significant part of their business. I think it is shortsighted a bit and could eventually pay for itself. Uhm, yeah, I remember AT&T, lawsuit and ubuntu . Then if someone is ok with being third-rate corporate footpads like BSDs, fine, but I think it could be a bit better than that.

Linux desktop market share is under 2%. Insignificant. Majority of Nvidia's profits are coming from enthusiast GPU (gaming) market : from Windows users.
Mobile and enterprise markets are much smaller, mobile in itself is more like an afterthought, not serious market for Nvidia.

I've noticed, thanks, so somehow I can't get source for some small device and hack on it. Because each and every proprietary wrench has (ab)used their freedom to show middle finger everyone around. I do not need freedom to receive so many fucks in my face, thanks.

Build something on your own?

GPL just keeps everyone equal. I think it is perfectly fair, especially as the way to interfact between devs and somesuch. Especially in large distributed project where nobody could claim they wrote all the code, so I do not get why they should be able to take over what they haven't even created, in first place.

For example. You work for the construction company. It provides you with the work place and assets. You get paid in return for your effort.
-Do you claim to own some piece of the building you built afterwards or it belongs to person/entity who paid for all of it? Question itself sounds like a joke.
-Do you claim rights to wander around in it's premises after building is complete, in the time of your choosing, solely because you think it's somehow now your right? Even more weirder notion.

Draw parallel with software company. It offers you a job, means to do your job with and pays you for your effort. Do you think you still have rights for the code you produce if it was really your work in the first place to produce it and you already got paid for it? Same with the companies that provide hardware. Ok, it's usually settled straight in working contract. At the moment though, I am speaking about moral right.

GPL is totally fair only from the end-user point of view, since he/she doesn't have to do jack sh1t anyway. He/she is solely the consumer. Dev has to think on GPL imposed limitations of the license every single time he/she wants to distribute it. How's that "fair" or "free"? One does not have to do anything than consume what you create, you have to jump trough loops to make him/her and license happy. No copyleft license is thus "fair" or really "free". How can something that dictates on it's rules on you be free?

I've seen enough of troublesome behavior from blobs, this is more than enough proof for me. When someone does not shows their source, I would question their motivation and since e.g. RH does BILLIONS without closing source, I wouldn't take "business" as excuse, sorry. Defective/troublesome business models hurting others are IMHO poor excuse.

I'm sure the code that handles RHEL licensing and subscriptions is also all fully open and available for everyone?

Somehow these secrets tend to hurt others, be it inability to fix bugs, vendor locking or treacherous/undesirable/malicious activity. So speaking for myself, I had enough of proprietary software treachery and consequences of vendor locks to start to actively dislike proprietary software. If someone is not happy with such treatment, go look into the mirror first. Customers have numerous reasons to dislike proprietary software and whole rise of opensource wouldn't be possible without major demand to replace proprietary software with something better than that. Yeah, bitching about your ultimate author rights haves its price: at the end of day, proprietary scums mistreating others could eventually figure out quite few people want to be treated like this. But some of them are clearly getting the idea way too late, which warrants some funny showcases . Interestingly most skilled and smart humans around are smart enough to get idea and get over stupid and counterproductive greed-induced bitching.

When was last time proprietary software like Windows bricked hardware like Linux on such a massive scale.. and it wasn't even considered "serious issue" by authors of the code. What I should think of the systemd dev's opinion that it's just "one of the many ways one could destroy their system"?
If it's not careless, ir-responsible, malicious and arrogant "we know it better" attitude, then what is? Yeah, we got your 200-300€ motherboard bricked, so what? You could have done it in many other ways.

Customers have numerous reasons to also like proprietary software. My country tried to use FOSS (estobuntu linux more precisely) for municipal and government structures in past. It was failure. I think, only thing that sort of stuck was OpenOffice and even that is slowly being replaced with MS Office again. In the end, FOSS was deemed more expensive to use than to continue using Windows in workstations.

I also decided to honor will of authors. I behave exactly like authors have demanded: if I'm not ag.ree, I do not use their programs. So, virtually no proprietary programs left on my computers. Just because I'm not agree with their fucking EULAs. Isn't it funny? Yeah, you could get your wish granted and let's see if you're happy with it.

What about the firmware in your PC's hard drives? :P

Somehow, proprietary authors also consider self like gods, who think they could pwn everyone, post arbitrary demands and get with it. Which isn't too far from fasc!sm or other kinds of draconian dictatorship either. But there was little catch. Customers aren't exactly fond of this kind of attitude. So e.g. proprietary BSDs in embedded died really quickly in favor of Linux. Yes, BSDs were here before Linux, but it haven't worked out.

You create something, you inherently own it. You decide what you want to do with it. Not the prospective user.
Or you would prefer the system where you build something (like house) and your neighbor claims it as his birthright? Or the producer of building materials comes around claiming that since you used his materials building your house, it also belongs to him/her/it.

If you don't like it, don't use it. And, FOSS BSD's came around 1 year AFTER Linux. Gave you already one lesson of history. Read it again.

Btw, Linus himself has said that if he had had something like BSD that worked on i386, he would never have started with Linux. He did it because he had no alternative and could not use Minix where he wanted it.

Nouveau on its own is opensource, but it seems BSD users perfer to hope nvidia will be kind enough. Then, it is really interesting idea to claim you're blob-free while booting off HDD running huge blob firmware, using blobbed BIOS/UEFI and totally disregarding running Intel Management Engine. Sure, formally it is fine, but from practical standpoint it isn't big achievement, because nasty blobs like ME are resident and running. And when achieved result grossly differs from what has been advertised, I call it "marketing BS". Or in best case it could be just ignorance/incompetence, so typical for BSD fans & overall project management. FSF is also could take similar blame, but there is Libreboot, so they at least honestly acknowledge problem rather than trying to downplay it or silently ignore it. Which is more fair approach to my taste. Interestingly I tend to agree OpenBSD users Nvidia is a really bad vendor. But I'm not sure we'll agree why exactly .

My 3-4 year old gaming PC: FX-8350, Asus M5A99X Evo R2.0, 16Gb (2x8) 1866MHz RAM, Geforce GTX 670 OC (sold week a go GTX 660Ti, got slightly better one cheap), LSI MegaRAID 9260-8i (2 Seagate Cheetah 15k7 300Gb SAS HDD's in RAID0 (OS), 4x2Tb WD Red's in Raid 6 (file storage). In the 3rd PCI-x16 slot is sitting Intel Pro1000MT dual server NIC.
Planning to keep it to the autumn, will see how the Zen pans out. If it sucks I'm going for Intel Xeon workstation hw. More reliable than consumer hw.

Count the dedicated processors and binary blobs running in it. Raid controller has 800MHz PowerPC running onboard it for example. Hope you won't get heart attack. It does not bother me in the least. Why should it?

Now show me blobless FOSS alternative with equal or better performance and capabilities.

Double standards is when you promise blob-free system, but it turns it is not a case. Just trying to pretend BIOS isn't your responsibility is childish. When SMI# handler knocks your blob-free OS out of the way, there is nothing blob-free OS could do. So it seems it lacks complete control on what's going on. Goal is not achieved. FAIL. Yeah, I value opensource for predictable behavior and lack of unexpected proprietary-style surprises. FSF is more fair, they've got Libreboot, so they at least acknowledge the problem, rather than feeding me up with stupid marketing BS. E.g. my devices are actually blob-free. I mean no blobs would kick my code out of system CPU. I have tight control over boot sequence, my code takes over early and no unknown blobs are called since this point of time. There're no major firmwares, except maybe SD-card, which is one of easiest things to get it to behave and it could also be say, raw NAND or SPI instead, so it is could be totally blob-free to the best of my knowledge. That's how I could accept blames if my device misbehaves. I think Linux devs got really reasonable point refusing to investigate bugs in tainted kernels running unknown blobs.

You know, majority of people does not simply care. What most people want? That their PC worked so that they could use it. How it works, how much is free, what happens inside, is not important. If you want to control absolutely every aspect of something it means OCD. In some cases it's survival trait (space environment for example), in some it's diagnose.

FOSS activists for Average Joe is nothing else than another form of possible nutcases. Like Jehovah's Witnesses who wander around knocking on random doors, annoying people, while trying to convince people to see World as they see.

[starshipeleven]

GPL is totally fair only from the end-user point of view, since he/she doesn't have to do jack sh1t anyway. He/she is solely the consumer. Dev has to think on GPL imposed limitations of the license every single time he/she wants to distribute it. How's that "fair" or "free"? One does not have to do anything than consume what you create, you have to jump trough loops to make him/her and license happy. No copyleft license is thus "fair" or really "free". How can something that dictates on it's rules on you be free?

Permissive licenses allow third parties to steal shit legally. GPL protects the developer's will of keeping the code free and open for whatever reason and avoids "working for big companies without being paid".

Of course if you don't care it's a drag, but for those that care it isn't.

[aht0]

How can you steal something that is already under permissive license in the first place? Explain me the fcuking logic behind such reasoning.

"I made basket full of bread and left it on street corner, so anyone who felt he wanted one, could take. By my own free will. Now, some dude in a T-shirt with writing "GPL" on it, stands there and yells at everyone that they all are stealing from me." Deal with your own sh!t and leave others free will well alone.

If someone wants to write stuff under BSD license/or not release their BSD derived code under same license, it's their own choice. For that matter, dev can GPL their work derived from BSD licensed code if need should arise.