I believe GPL enforcement in general, and specifically around the Linux kernel, is a good thing. Because of this, I am one of the Linux copyright holders who has signed an agreement for the Software Freedom Conservancy to enforce the GPL on my behalf. I’m also a financial supporter of Conservancy.
That I hold any copyright at all to the work I’ve done is actually somewhat surprising. Usually one of the documents you sign when beginning employment at a company is agreeing that the company has ownership of work you do for them, and even things you create off-hours. Fair enough. But, my current employer does not do this. Its agreement lets its employees retain individual copyright to their work for open source development projects. I haven’t checked, but I suspect the agreement I signed with my less-steeped-in-F/OSS previousemployers did not.
It’s something to ask about when considering accepting a new position.
I consider myself an idealist, but not a zealot. For projects I’ve started, I’ve used MIT, AGPLv3, MPLv2, GPLv2, GPLv3, LGPLv2, and Apache 2.0 licenses, based on the individual circumstances.
I believe if you’re going to build upon someone else’s work, it’s only fair to honor the rules they have set — the license — that allow it. Everyone isn’t doing that now with Linux, and are using the ambiguity over what is a “derived work” as a fig leaf. Enforcing the GPL is the only way to ensure the intent of the license is honored. We’ll also hopefully eventually gain some clarity on exactly what constitutes a derived work from the courts.
target-isns recently was added to Rawhide, and will be in a future Fedora release. This add-on to LIO allows it to register with an iSNS server, which potential initiators can then query for available targets. (On Fedora, see isns-utils for both the server, and client query tools.) This removes one of the few remaining areas that other target implementations have been ahead of LIO.
Just got an email full of interesting questions, I hope the author will be ok with me answering them here so future searches will see them:
I searched on internet and I don’t find some relevant info about gluster api support via tcmu-runner. Can you tell me please if this support will be added to the stable redhat targetcli in the near future? And I want to know also which targetcli is recommended for setup (targetcli or targetcli-fb) and what is the status for targetcli-3.0.
tcmu-runner is a userspace daemon add-on to LIO that allows requests for a device to be handled by a user process. tcmu-runner has early support for using glfs (via gfapi). Both tcmu-runner and its glfs plugin are beta-quality and will need further work before they are ready for stable Fedora, much less a RHEL release. tcmu-runner just landed in Rawhide, but this is really just to make it easier to test.
RHEL & Fedora use targetcli-fb, which is a fork of targetcli, and what I work on. Since I’m working on both tcmu-runner and targetcli-fb, targetcli-fb will see TCMU support very early.
The -fb packages I maintain switched to a “fbXX” version scheme, so I think you must be referring to the other one 🙂 I don’t have any info about the RTS/Datera targetcli’s status, other than nobody likes having two versions, the targetcli maintainer and I have discussed unifying them into a common version, but the un-fun work of merging them has not happened yet.
As mentioned in the beta release notes, the kernel in RHEL 7.2 contains a rebased LIO kernel target, to the equivalent of the Linux 4.0.stable series.
This is a big update. LIO has improved greatly since 3.10. It has added support for SCSI features that enable VMWare VAAI support, as well as data integrity (DIF), and significant iSER work, for those of you using Infiniband. (SRP is also supported, as well as iSCSI and FCoE, of course.)
Note that we still do not ship support for the Fibre Channel qla2xxx fabric. It still seems to be something storage vendors and integrators want, more than a feature our customers are telling us they want in RHEL.
(On a side note, Infiniband hardware is pretty affordable these days! For all you datacenter hobbyists who have a rack in the garage, I might suggest a cheap previous-gen IB setup and either SRP or iSER as the way to go and still get really high IOPs.)
Users of RHEL 7’s SCSI target should find RHEL 7.2 to be a very nice upgrade. Please try the beta out and report any issues you find of course, but it’s looking really good so far.
If you have a bit of life experience, you’ll see that it often takes a disproportional amount of political effort to get people that are stubbornly doing the wrong thing to change their minds. Most of the time, you would get much more done by just doing it yourself instead of spending months trying to get someone else to do it, or at least to stop blocking you from doing it, then to stop undoing your work the moment they let you do it correctly. You know that you’re in a problematic environment when nothing ever gets done unless the people in supervisory roles aren’t looking and know nothing about what you’re doing.
Also, you really can’t go into a project wanting to tear the whole thing down when no one else shares your opinion. That’s a recipe for disaster for all involved. It will turn toxic. Fast. The only time that’s feasible is when you have the power to boot anyone that disagrees with you. You will have to be a dictator to make it work.
Contrary to what RHEL 7.1 release notes might say, RHEL 7.1 should be fine as an iSER target, and it should be fine to use iSER even during the discovery phase. There was significant late-breaking work by our storage partners to fix both of these issues.
Unfortunately, there were multiple Bugzilla entries for the same issues, and while some were properly closed, others were not, and the issues erroneously were mentioned in the release notes.
So, for the hordes out there eager to try iSER target on RHEL 7.1 and who actually read the release notes — I hope you see this too and know it’s OK give it a go 🙂
We went down to Pioneer square and just got some footage of random folks, trying not to be too obtrusive. I used my Blackmagic Pocket Cinema Camera, along with the Metabones Pocket Speedbooster and a Nikon 55-300 zoom. Unfortunately my monopod’s bottom foot needed tightening, so the video was a bit shaky. Shooting longer distances didn’t help, either.
Back at home, I cut the best parts together and wrote an appropriate voice-over text. I tried reading it myself first (sitting in the car in the driveway, to minimize reverb) but it wasn’t nearly as good as Jennifer’s readings, so that’s who you hear. Then I quickly added a piano based score using Ableton’s Piano sample set, and that was it.
It turned out very differently from other submissions. It’s a long shot but who knows? For me, I learn something new in each little project I complete, so just for that it was valuable to me.
I primarily work on Linux, so I put this in my Emacs config:
; Linux mode for C
'((c-mode . "linux") (other . "gnu")))
However, other projects like QEMU have their own style preferences. So here’s what I added to use a different style for that. First, I found the qemu C style defined here. Then, to only use this on some C code, we attach a hook that only overrides the default C style if the filename contains “qemu”, an imperfect but decent-enough test.
'((indent-tabs-mode . nil)
(c-basic-offset . 4)
(tab-width . 8)
(c-comment-only-line-offset . 0)
(c-hanging-braces-alist . ((substatement-open before after)))
(c-offsets-alist . ((statement-block-intro . +)
(substatement-open . 0)
(label . 0)
(statement-cont . +)
(innamespace . 0)
(inline-open . 0)
(block-close . c-snug-do-while)
;; structs have hanging braces on open
(class-open . (after))
;; ditto if statements
(substatement-open . (after))
;; and no auto newline at the end
"QEMU C Programming Style")
(c-add-style "qemu" qemu-c-style)
(defun maybe-qemu-style ()
(when (and buffer-file-name
(string-match "qemu" buffer-file-name))
(add-hook 'c-mode-hook 'maybe-qemu-style)