Aint just SAMBA
Where do you think they get their iSCSI from and in some cases their FC target implementations too.
Linux and *BSD have completely changed the storage market. They are the core of so many storage products, allowing startups and established vendors alike to bring new products to the market more rapidly than previously possible. Almost every vendor I talk to these days has built their system on top of these and then there are …
I wrote an open source file system that has been used in many tens of millions of devices. I have not received one cent of royalties or donations from the people building devices or the flash vendors who have sold billions of dollars of flash that use the file system.
About the only people who have made money out of this are Microsoft through gouging "Android tax" and alleging that my code infringes copyright (a claim from which they subsequently backed down). By my back of the envelope calculations they probably made $50M or so out of open source use of my work.
But, hey, that's open source. If you get all worked up about it you'll just get ulcers.
"About the only people who have made money out of this are Microsoft through gouging "Android tax" and alleging that my code infringes copyright (a claim from which they subsequently backed down)."
If they've been collecting money on your behalf, you should claw it back... :)
"If they've been collecting money on your behalf, you should claw it back... :)"
Unfotunately they have been collecting it on behalf of themselves.
I got an email once from someone at HTC expecting some free technical support. It happened to be on a day when I was feeling rather pissy. I suggested they contact Microsoft for support since they were paying Microsoft.
It's not just a debt owed to the open source community. It's also a responsibility to your customers. This side of the story doesn't even depend on whether the software is open- or closed-source.
OpenSSL [Heartbleed] is a good open-source example of what can happen when many parties rely on a particular bit of software, but don't invest in the maintenance of that software. The best closed-source example might be Microsoft's unending train of patch management, often fixing bugs in decades-old software, because in the past they didn't take security seriously enough.
With closed-source software, your options are pretty much limited to paying license fees for the software and hoping that the developer uses those fees wisely in development and support.
With open-source software, there are more options, including direct involvement in development, code review, testing. Even a good bug report is a boon to developers.
Long story short: Open-source software (or even prebuilt closed libraries) isn't a way to build something for free: it's a way to build it fast. You always pay, whether it's in license/support fees, community involvement, or in lost reputation and income because your customers lose data or can't secure it properly with your systems.
You have the option to participate in open source true. The reality for probably 98% of orgs out there is even with that prospect they do not participate because they don't have the skills/etc to do so.
I've seen countless companies including every one I've worked for use open source stuff for various things and pretty much never contribute back. If they found problems with some open source package the solution was typically not to use that package and try something else, rather than spend time beyond basic community mailing lists to get help resolving it.
Many folks see open source not as freedom but as "don't have to buy something". Which in some cases creates many more problems than going out and actually buying something that may work better.
(Linux user for 18 years, 16 of those spent supporting it and other open source tech along side commercial tech, so not a MS fanboy by any stretch!)
If your a Linux user and want to support open source, use a commercial distribution like Red Hat. You get quality software, and you know you are supporting a lot of open source projects at the same time. It's a much easier sell to management then saying they should donate $$ or hire some developers to contribute code back.
But it's open source so every freetard out there is busy spending every waking minute fixing bugs and auditing code. If you have big business fat cats doing the work we will have to pay for it and that costs money which we don't want to have to spend in our utopian freetard society.
Also - down with bankers.
> make sure you ask the question: "How many developers do you have submitting code ...
Nah! Code is easy, code is "fun". You don't have to pay hobbyists to write code: they do it for free.
Documentation is boring. Documentation is dull. Documentation is hrad 2 get wright.
Testing is even worse.
Project management is next to impossible.
So if companies want to contribute to OSS, the best thing for the community and its users would be to leave the code to the geeks who like doing it and to add far more value by testing the stuff they produce, using it, managing the change control and writing books, articles, man pages, wikis, examples (preferably working examples) and FAQs. Those are the things that are missing from most projects - and are the biggest impediments to the take-up of "free" (free as in no cost: so long as you put zero value on the hours or days it can take to wrangle some of this stuff into working shape - or realise it's irredeemable crap and you've just wasted a week on it).
That's where the biggest contributions will come from. Even though those contributors won't get the recognition and kudos. That's why companies are in the best position to donate those efforts.
Another better question might be "where can I download your source from?", especially if you then really make sure that you can rebuild a working box from that source.
If you can't, it's either a GPL violation (let the copyleft owner know!), or use of the "mere aggregation" exception to tie you in to that particular vendor for support. Should they cease maintaining the software for the hardware you have come to depend on, you may be forced into an expensive hardware replacement for lack of a three-line patch to the bundled software.
These things are not like routers. It's rather more expensive and disruptive to have to junk and replace them if and when a never-to-be-fixed security problem is revealed.
Thanks for the shout-out ! It's lovely to hear someone mentioning Samba in an article (sounds like 1997 again :-).
To be honest, many of the vendors who 'move on' from Samba are pushed to do so by their marketing department - not be the engineers. The marketing people like to say "our implementation is unique" - hoping to mean "better" of course :-). That's not always the case :-).
I know of at least 2 vendors mentioning no names of course :-) whose engineers have privately told me that's what happened..
Still, there's enough work to keep everyone busy on Samba for a good number of years yet !
As I keep telling the young-'uns - if you're a qualified Samba coder I can get you a job tomorrow (many postitions in Silicon Valley). But they keep wanting to do the webby stuff... :-(.
As I keep telling the young-'uns - if you're a qualified Samba coder I can get you a job tomorrow (many postitions in Silicon Valley). But they keep wanting to do the webby stuff... :-(.
TBH, I would rather be coding real stuff (C/C++) rather than these baby scripting languages everyone seems to be hot about (JavaScript, Ruby, Python) and webby stuff like AJAX. I've managed to stay on Java at least and doing mostly back-end stuff, leaving the front-end things to the javascript kiddies.
However, I'd love to see something better than Samba come out, something that was both multi-platform (Linux, Unix, OSX, Windows) and have the advantages of, say, NFS without having proprietary "security" like SMB (which depends on some MS protocols). Why can't we have something like that?
We can't have something like that because Microsoft won't build it into their clients :-(.
Same reason we can't have decent filesystems (ext4 anyone ?) on USB sticks - Microsoft insist on FATxxxx-only to keep the monopoly rent on the patents I'm afraid.
Still, SMB is pretty multiplatform these days - with the unix extensions turned on in the Linux CIFSFS client and Samba as a server it's pretty close to UNIX->UNIX semantics. Reminds me of RFS it does :-).
And it's *certainly* better than NFS (which turned into a monster the moment they tried to import wholesale some of the CIFS/SMB stateful semantics, and the ACLs, god help me don't mention the ACLs :-).
Same reason we can't have decent filesystems (ext4 anyone ?) on USB sticks
As already stated ext[234] works just fine on a USB stick, but Windows can't read it.
ntfs-3g on Linux has had write support for NTFS on Linux for quite some time. I'm not sure I'd trust my life to Linux writing reverse-engineered NTFS, but for read-only use it's never let me down, and my occasional forays into writing well-backed-up or disposable NT filesystems have also not failed in recent years.
Finally, KVM is now pretty solid, so you can invoke Windows in a Window under Linux, and access the Linux filesystems across the (virtual) network. Using free-beer VMware player you can do the same with Linux in a Windows window.
We can't have something like that because Microsoft won't build it into their clients :-(.
Even when they do have support for file-systems, they may not have support for it in the way you want to use it.
I wanted a file-system that would be recognized on MSWindows and Linux. With full-write support etc. udffs looked a good idea, as I knew MSWindows supported it (since it's what DVDs use). However - it only supports it if it is on an optical disk! If it's on a hard-drive then it doesn't want to know about it.
This was a few years back, so it may be different on Windows8, but I can't be bothered to check...
How do you read udffs in Linux if it's on an HDD? I've been trying for ages. We have some old Fostex hard disc-based audio recorders that use this format and I can't read the discs, whatever I try. At the moment the only way to re-install the things is to format the discs in the machine (takes - literally - all night for an 80GB HDD) and then upload audio files over FTP (for those machines with network interfaces) using the player's highly unreliable and slow FTP server. 16 or 20 tracks of 15 minutes or so each takes at least a whole day, and if number <n-1> fails, you have to start all over again.
I would *love* to be able to image the existing discs using (say) dd...
M.
dd is just a binary copy tool, it cares not what the contents of the source are. If your disks are identical sizes, a simple dd if=/dev/sdx of=/dev/sdy should do the job - obviously this will just create a binary copy of the source on the destination disk.
If you want to access the UDF file system itself, you should be able to mount it like you would any other FS:
mount -t udf /dev/sdx /mnt/somewhere
I'm on holiday so this is going to be a bit abbreviated. I've a suntan to work on.
The comments about NFSv4 are well wide of the mark. But that's to be expected, since there are really only two file protocols left; CIFS (sorry SMB )and NFS. Competition is good. And even MS has developed an NFS server.
More on topic, vendors play a huge part in open source. NetApp for many years and now Primary Data pay for nearly (all?) the entire Linux NFS client developer community. And we (NetApp) contribute significant amounts of money to the Linux Foundation, amongst other open projects.
Off to toast myself under the Aegean sun. It's free, but not the beer that goes with it.
ZFS + CIFS/NFSv4 should be good enough. (i.e Nexenta and they do support it).
This has been the closest I've seen to this. I would actually like ZFS support on every OS, but it seems it also crashes against the Windows barrier. I've been able to use ZFS as a multi-platform filesystem between OSX, Linux and Solaris though.
I still would like a secure version of a NAS protocol. I don't think "routing over http" is an issue anyway, as most of these services are usually needed within an organization (thus everything's inside the corporate network) or within a home office (same thing, no firewall problems).
What's the real barrier against someone doing their own filesystem driver? Is this actually closed off by MS legalese? There are (expensive) suites that let your Windows box read/write HFS+ partitions, so it shouldn't be that much of a problem, should it?
I actually am quite impressed with SMB3 as a protocol. It is very nicely done. Samba (and the Linux kernel client as well) has made a nice start with a usable, stable, practical SMB3 implementation, implementing all of the mandatory features, and some of the optional features (with many more in progress). Additional help in development and testing of various optional SMB3 features (especially in support of RDMA, and improved clustering, virtualization) would be much appreciated and very timely.
We shouldn't forget some of the work going on to extend NFS, which I also find interesting, but SMB3 was nicely designed.