Hacker News Reader

Comment by nrclark | Hacker News Reader

I hope this doesn't displace Samba.

NFS is a pain to use specifically because it's compiled into the kernel, and reads config files that have to live in /etc. That makes it very hard to run or control as an unprivileged user. It also means that a file in /etc needs to be writeable. That makes NFS servers very hard to start, stop, and configure as part of a test bench.

Kernel NFS also essentially displaced all userspace NFS servers (that I'm aware of anyways). At least, I've never been able to get a userspace one to work.

I like Samba specifically because it's easy to configure, start, and stop from userspace. I don't want to see it get obsoleted.

View on HN

Samba is GPLv3, this is GPLv2 so they may be serving different communities ultimately. At least where I am GPLv2 - folks are MUCH more comfortable with that.

Not sure but one area would be embedded devices (think security camera with a SD card in it). This would really let them serve a file share for video browsing, without having to give out their keys to the devices themselves (GPLv3 is both viral and has all sorts of what are called anti-tivoisation provisions that means developers are more limited in what they can do with the code in terms of use).

> anti-tivoisation provisions that means developers are more limited in what they can do with the code in terms of use

Developers are only "limited" from locking users out of their own device

We need to be CRYSTAL clear here.

Developers are the ones contributing to these open source projects.

Developers are the ones picking which licenses to use (and which software to develop with).

Developers or their employers etc are setting the terms of sale with their user or regulatory agencies around product sales (which duty cycle limits, thermal cutoffs, RPM governors on engines, speed limits on vehicles like scooters and the list goes on and on).

Historically, open source didn't not have a restriction on use. In other words, even if Linus doesn't like military stuff, some govt contractor could use linux in a submarine. Similarly, if Linus things Trump was an idiot, he couldn't block trump from using Linux. Similarly, if a developer needed to set power emission limits on a device they shipped, or a governor or anything else they could lock the device so that user couldn't change power limits or duty cycles or other parameters. This is in many cases critical to these product sales.

Especially in industrial applications (but even automotive), the mfg and their developers often DOES NOT want users messing with the duty cycles, temp limit cutouts or other issues.

GPLv3 changes the calculation hugely here. Mfg's used to be basically free to use the software how they wanted, they just had to give back to other developers.

Under GPLv3 all this changes. GPLv3 requires folks to unlock devices, give up encryption keys. Because it is developers deciding on the licenses being used, GPLv3 is MUCH less acceptable to a lot of developers who don't want to be blocked from using projects they contribute to in the ways they or their employer wants.

So this is a very real limit on developers freedoms here. We keep on hearing from GPLv3 folks how much better the GPLv3 is - I and others disagree -it's a fundamental change to the GPL historic intent and function.

The intent of FSF was always to protect user freedoms - where users can also be developers - and not to protect developer freedoms - where developers are a separate class from users.

GPLv2 was share and share alike. Developers could work together on common software, and then each use it how they wanted within their orgs.

It also helped drive down proprietary forks.

Regardless of FSF desires, this is how it was used.

As GPLv3 was getting developed (in secret largely) communities like the Linux community started picking up on the big change coming and updated their license to be clear that Linux for example is GPLv2 ONLY (!) to avoid having the FSF change the usage and rules of their project on them.

> As GPLv3 was getting developed (in secret largely)

The above is incorrect. GPLv3 was developed via a completely open process of development, documented very well here:

https://opensource.com/article/18/6/gplv3-anniversary

Apple lawyers participated. From the above link:

"Lawyers representing vendors' and commercial users' interests provided useful suggestions for improvements from a legal and commercial perspective, but these often took the form of making simply worded provisions more verbose, arguably without net increases in clarity. .. One lasting contribution of GPLv3 concerns changed expectations for how revisions of widely-used FOSS licenses are done. It is no longer acceptable for such licenses to be revised entirely in private, without opportunity for comment from the community and without efforts to consult key stakeholders."

The above is correct - this would take more to cover here but I'd quickly suggest maybe watching something from active developers?

You need to realize that the basic principles were NOT asked for by the major users of GPLv2. When initially discussed way before v3 they were rejected. There was no scoping of need here, certainly not by major projects like Linux.

https://youtu.be/PaKIZ7gJlRU?t=130

(start at beginning if you want more context).

Ubuntu went through this as well, and basically had to get the FSF to (privately) say that they wouldn't enforce the key release process for tivoization against Ubuntu. It was that or use the Microsoft shim.

It was just one sketchy / dicy deal after another. Crazy how wrong GPLv3 was in terms of a natural revision to v2 for developers. I doubt Linux has changed to GPLv3 or will personally, but we will see I guess. Good to see some GPLv2 options here that people can use in devices etc.

And the BSD's and MIT licenses took off as a result, GPL overall lost out as a result of the v3 mess in my view (as a GPLv2 fan that's a bummer).

Yes, the drafting part was "open" in the sense that lawyers got involved and the license got VERY very complex. If that's a win - go for it - most developers just passed on it.

Linus had no part in the drafting of GPLv3, so no I'm not surprised by that video at all.

I participated in the GPLv3 drafting, and your claim it was full of "one sketchy / dicy deal after another" is NOT correct.

You might not like how it turned out (and I myself have serious misgivings, mostly around the betrayal by the FSF in not using it for their own projects because they're frightened it will make them "unpopular") but it accurately reflected the wishes of the drafters at the time.

Nothing secret or sketchy about it at all.

First - the GPLv3 was NOT drafted in an open process.

IF they had bothered to ask folks shipping GPLv2 code what they would want in a GPLv3 they would have gotten a much smaller scope. Maybe some patent improvements and some other cleanups.

The idea that they solicited developer community input around the GPLv3 in terms of what it should cover is a joke. It really is a lie basically. Yes, they solicited users and activists, but not the actual folks giving their labor away for free. So they tried to basically trick a bunch of folks by hitching onto the v2 or later standard language - using a license with very different terms - SO SKETCH!!

It really illustrates how immoral and unethical the drafters of v3 were and left a sour taste with a lot of folks.

Some folks had a heads up around what would be coming - Linus got an early look and went immediately to GPLv2 only to protect against this attempted hijacking.

----

Once they did get it out - now FAR longer and harder to read, lots of special cases etc, they'd created a real problem, it was hard to work with this thing.

They kept on lying about having to release or not release encrypting / signing keys.

Ubuntu refused to use a v3 bootloader until they did some kind of backroom deal with FSF where FSF, as author of license, did some private interpretation Ubuntu could rely on. Ubuntu wasted a metric ton of time on this, and until they got the secret signoff were not going to budge (ahh, again a sign they ignored major dev communities).

I could go on, but it's not worth re-hashing. v3 basically ended GPL as the standard OSS license, I think folks are sick enough of it that MIT / Apache etc are going to be the future. Even the idealists among us learned some important lessons in the process.

I think GPLv3 and especially AGPLv3 will be the home of things like contributor licensed software to one company - it's basically unusable but they can call it "open source" sort of like Microsoft shared source stuff and then license commercially by keeping copyright in a for-profit vs in a community of contributors. If they can find devs willing to contribute under that - more power to them. But that wasn't the early model under GPLv2.

So the drafters fractured the GPL copyleft landscape (bad), messed up the popularity of this type of license (bad), didn't have the integrity to do a GPLv3 in keeping with v2 (bad).

It's kind of incredible, there was this AMAZING license in v2, I mean, folks had really consolidated around it in a fair number of major areas and ways. I sometimes can't believe that got torched for MIT and Apache (which really are not copyleft though they are open source).

----

Anyways, having failed with v3, I'm expecting they will try to back fit v3 by saying v2 is really v3? Look for some very strong pushback on that.

"Dave, this conversation can serve no purpose anymore. Goodbye."

Some quick thoughts here:

Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.

Please don't post shallow dismissals

I've worked to provide some background / context around my comments. Instead of indicating I was misinformed perhaps, that Ubuntu perhaps never was concerned about GPLv3 in a bootloader, we get a pretty content free dismissal. If you have little to add, perhaps just let the comment thread end?

These types of content free responses do little to advance a discussion on a topic.

The GPL was always meant to ensure that the user had the freedom to change and use their software any way they like; v3 just clarified that you can't give users the code but then prevent them from actually running modified versions. By your logic, devs are "limited" by GPLv2 because they can't possibly bear having to expose their own proprietary code.

Under GPLv2, you can use the code base you contribute to how you desire.

With GPLv3 there are additional restrictions on how you can use the code base you contribute to.

Okay, I desire to run the software on the hardware that I literally bought to run it.

The point I'm making is that DEVELOPERS pick the license, and formerly for them they didn't lose much of their freedom by picking GPLv2, just others could also take code and do things.

With GPLv3 that changed. Others could still take code and do things, but now they COULDN'T do things.

Users desire is not part of this, and is a boring and old trope of OSS where users, doing no work and paying no money - make all sorts of demands. If that is the FSF attitude then good riddance to them, it's old and burns everyone out. They probably have attorneys going crazy and burning out people even more.

As do I. As a customer buying some hardware, I would of course like to have access to the software stack as well. And be it only for long-term support after the device becomes unsupported. But for various reasons, a lot of companies (and it is usually the decision by the company, not the employed developer) selling the products, don't want to give you this ability. Sometimes it is for making more money, sometimes it is for legal and safety reasons, just think of the automotive sector.

If a company decides to sell you a product with closed software, they will do so and GPLv3 won't change this. Not because they are not complying with the license terms, but because they won't touch any GPLv3 licensed software.

Somehow I am quite sure "developers" are not the ones deciding to lock out their own customers here.

Well someone had to implement firmware that checks for signatures on software and doesn't provide the user any way to sign their own

Right, but the decision to implement this isn't made by the developer. It is made by the project lead/management.

> ...GPLv3 is...a fundamental change to the GPL historic intent and function.

That’s a pretty bold statement. As a FS developer since the 1980s (not just code, for example I wrote the library license) the GPL3 feels like it precisely captures the intent of the original GPL but updated for today’s world.

Of course in the interest of choice you aren’t forced to use GPLv3 code any more than you are forced to use a piece of proprietary code with license terms or cost you don’t like.

Many developers disagree.

https://www.youtube.com/watch?v=PaKIZ7gJlRU

Gives just one example of folks who are active in this space thought. GPLv3 is very different than v2.

Edited: Some quick stats as well:

Permissive licenses are on the rise. In 2012, 59% of components' licenses were copyleft and 41% permissive. In 2019, that has fully swung the other way with 67% of components having permissive licenses and 33% copyleft. Permissive licenses face few restrictions on how others can use components.

MIT was the most popular license in 2019 at 27%. The MIT license lets folks do almost anything they want with the code as long as they attribute it and don't hold you liable.

Apache 2.0 jumped over GPL 3.0 in 2017 to number two and it's still there with 23%. It gives you patent rights while allowing modifications and distribution of larger works under different terms and without source code.

- Techrepublic

I don’t understand the point you’re making. You asserted that that v3 is inconsistent with the historical intent of the gnu project; I argued that it was not, based in part on my involvement going back into the 90s.

Of course you can disagree with me, but the choice various developers might make is unrelated to that. It merely shows that various people don’t agree with the goals of the FSF. Which may be interesting but has nothing to do with the licence’s fidelity to the FSF’s objectives.

Too bad it isn’t gpl2 compatible BSD so Apple could replace their shit version.

No question - that was a major regression apple side.

That said, I think apple DOES ship GPLv2 code don't they? Or am I mistaken there. I thought it was GPLv3 that was toxic at apple?

is there a CIFS GPLv2 or BSD client side implementation? This might not be what is needed to fix the Apple SMB situation.

They don’t ship GPLv3 code at all - and they try there dardnest to get rid of GPLv2 if they can.

The old Samba was GPL2 I think but it got too old.

If it helps, as far as I'm aware Ganesha [1] is still widely used, supported, in some cases faster than the kernel implementation, and can be pointed at an arbitrary config file.

[1] https://github.com/nfs-ganesha/nfs-ganesha

> That makes it very hard to run as an unprivileged user?

Huh? You can't run it as an unprivileged user at all.

You want NFS-Ganesha if you want a userspace NFS server. Development it active and it's the only OSS NFS implementation I've seen that can handle an Active-Active HA configuration with Kerberos.

In theory you need CAP_SETUID and maybe a few other to run it with less privileges. That can also be done theoretically with another user than root if you can hack things appropriately. In practice the hacking part is hard.

Isn't NFS also dead? It basically believes you are root if you say you are.

And NFSv4 apparently requires Kerberos? WTF? Was it designed only for MIT use? Why can't they support simple things like SSH keys?

NFS is what you use if you want seamless file shares on Linux. Pretty much every other option has been junky or lost me data.

It depends on what kind of data is important for you.

In my Linux file systems (and also in my FreeBSD file systems), extended attributes are very important for me.

The older NFS versions (v2, v3 and early v4, before Linux 5.9) do not support extended attributes, so I was always forced to use Samba shares, which for me worked OK, including with the sharing between Linux and FreeBSD.

I'm just happy with the files themselves being intact, but IME even that was difficult to achieve with non-NFS solutions. SMB was notoriously difficult to set up, and things like WebDAV or SFTP would have severe write loss problems when I tried to use them like an interactive local filesystem. NFS is rock stable.

The default for NFSv3 is to map client-side root to server-side nobody, unless you explicitly tell it not to. (Which I had to do once to run a diskless workstation with an NFS root filesystem.)

NFSv4 uses idmapd with a defined "domain," unlike direct uid/gid mapping of earlier versions.

When the idmapd daemons on either side cannot agree on the domain, all users will be "squashed" to the default NFS user.

Root is always squashed, unless nosquash is specified in /etc/exports (which goes for earlier protocol versions as well).

NFSv4 [cleartext] does not require kerberos. Kerberos can be used to encrypt the data stream between client and server, but this can also be accomplished with stunnel over TLS (google "nfs encryption" for details).

A very clean approach to NFS authentication is using it in combination with wireguard. With NFS you can limit access to certain IPs or IP ranges. With wireguard you add authentication that these IPs are really the users/group of users. Also it adds encryption to the actual file transfer.

> I hope this doesn't displace Samba.

It doesn't seem to be the objective. For one, this is a very old version of SMB protocol (v3, while SMB doesn't have big releases anymore the current one is v4). Also, Samba have the user space tooling that this project explicitly doesn't want to reimplement. And it seems that both implementations are compatible with each other.

It does seem to me that the main objective here is to have a very efficient implementation of SMB for embedded devices.

Samba versions don't correlate with the protocol versions.

The latest SMB protocol versions is 3.1.1.

gatling has basic Samba support and is really minimal.

If you start it without arguments it will just serve the current directory

what about ganesha?

Reply on news.ycombinator.com