I call bullshit. This chart shows the power-delivery capability between traditional lead-acid batteries and Ni-Cd batteries.
WTF? First off, when did Lead-Acid batteries enter the discussion? You aren't going to have a portable drill with a Lead-Acid battery attached to it.
Second, that PDF doesn't show what sustained loads the batteries can take, only current discharge over time/tempurature, and voltage drop.
Third, the PDF says the EXACT OPPOSITE of everything you are saying in your post! You say NiCD batteries drop power output, while the PDF says:
The voltage of a lead-acid battery, on the other hand, decreases much more notice-ably as it is used.
That matches my direct experience, and everything I've ever read about nickel cadmium and Lead-acid batteries, while your statement is just completely wrong.
(Perfect explanation is use a Ni-Cd battery bank in a flashlight, run it down, and use a Li-ion battery pack in the exact same flashlight - you'll notice the Li-ion battery bank provides constant power output until it's DEAD, meaning the bulb stays bright instead of gradually dimming with use.
This is just completely wrong. NiCADs will provide close to their full voltage/current until they are damn-near completely depleated, and then they will very suddenly dim.
I really can't imagine how you've managed to get NiCAD vs Lead Acid so completely backwards.
Nations that have been around a lot longer than the United States of America have had plenty of time to think about waste management
Yes, older countries like China, Russia, etc. know better... Whoops, not what you had in-mind, huh?
I guess the more elitist Europeans like yourself don't need any facts to support your claims, either.
Hint: The USA is a big place... bigger than all of Western Europe. In the USA there are different states, where the laws may vary, just like countries in Europe. Some of these states are actually significantly AHEAD of Europe in environmental regulations. In fact California has had a law somewhat similar to this since at least 2000.
15 of the the top 20 most liveable counties are in the EU. Most and Least Livable Countries: UN Human Development Index, 2005 see http://www.infoplease.com/ipa/A0778562.html
I must say, I find it absolutely HILARIOUS that you're using that list to explain your desire to leave Australia for Europe, when Australia is the #3 most livable country according to that list.
and skin cancer sucks
Wear sunblock. Plant a few trees. etc.
I'll take the desert, over the freezing North Atlantic, any day.
I'm using an AMD64 3500 and mplayer chugs away 5-10% cpu (as measured by top) with a significant ~5% CPU usage increase in X, a total CPU usage of 5-11% at anyone moment throughout the movie in front of me.
From the increase in X CPU usage, it sounds like you're perhaps using a junky on-board videochip (or perhaps something with lowsy drivers), or using an output method like x11 instead of one of the many overlay outputs (which hardly even involve X). I'm just using an ultra-cheap, 4 year-old GeForce4 AGP card myself.
Since you're on an AMD64, I wonder if you've compiled it as a 64-bit or a 32-bit binary; if you compiled it yourself or are you using a binary package (runtime CPU-detection blows)? What version of GCC did you use, which version of MPlayer, which kernel version, etc.
Certainly the AMD64 version of MPlayer hasn't gotten nearly as much hand-written assembler optimization as the standard x86 version has, but your performance should still be better...
I'm also playing PAL which doesn't require any funky inverse telecine or deinterlacing most of the time, so logically NTSC movies (720x480) would require more CPU time.
You're assuming inverse telecine and deinterlacing is CPU-intensive. It can be, with filters like pullup and kerndeint, but most of them, like filmdint, use practically no CPU time at all. So the larger resolution of PAL material may be more of a slowdown than inverse telecine or deinterlacing.
The CPU utilisation of mplayer is great but it's not 1% great.
The fact that you aren't getting it, doesn't mean it's not true. I can think of many reasons your CPU usage would be higher than it should be...
Perhaps you're using a large cache value, while -nocache is actually fastest. Perhaps -rtc support is causing a slowdown, and you can use -nortc for a speed-up. Options like "-lavdopts fast" work nicely in most cases as well.
After this, people will chuck their cell phones into the nearest river, even more directly polluting the environment they tried to protect.
Now WHY would someone do that? Out of spite for the new law? No, I think not.
This requires shops to collect used batteries at NO COST, so I can't see any reason someone would do something as insane as going out of their way to toss it into a river.
It's my experience, since many versions during the last three years of MPlayer and Xine.
Yes, well... Either something is very wrong with your system, you're completely mistaken, or you're just making things up. I find the latter to be most likely.
Posting at +1, UID of almost 900,000, no details or info to back-up your extremely vague claims that fly in the face of all logic.
If you've got files that crash MPlayer and not Xine, upload a sample somewhere so it can be verified.
If MPlayer is insanely slow for some reason, perform some detailed benchmarks with both programs on the same videos, and post the full output somewhere as well. You can send it to the mplayer mailing list as well.
Under absolutely ALL circumstances. MPlayer has been heavily optimized for speed, while XINE hasn't. I've never before seen ANYONE claim Xine was EVER faster.
If you're actually seeing something like that, and not just trolling, either you got a poorly made binary package, or you were doing something like using the wrong output method for your system.
Some defective AVIs and VOBs I played on Xine, but made MPlayer hang.
Also something I have NEVER heard from ANYONE, ANYWHERE. MPlayer is much more tolerant of errors, and will play far more media types. If you're seeing some bug, you should report it, and perhaps provide a sample.
XVideo and ALSA is all you need.;-) No seriously, for most users, this should not be an issue.
vidix is faster than XV in just about all cases. gl is faster if your drivers have OpenGL support, and MUCH, MUCH, MUCH faster on HD material.
svga/fbdev support makes it possible to play videos even without X11 installed, and can be faster in some cases.
> Doesn't have a fraction of the great video/audio filters that MPlayer does.
see MEncoder comment.
No, I'm not just talking about encoding. Good inverse telecine filters are absolutely necessary in the US and other NTSC countries. There are plenty of other filters like overlays for interactive on-screen graphic interfaces (eg. Freevo), filters to fix videos which have been improperly encoded, like deinterlacing telecined content, numerous postprocessing filters, filters to remove TV station logos, etc.
i switched from mencoder after trying, and failing, to prevent it from dropping frames it decided were "similar" to previous frames.
No, mencoder only drops exactly identical frames.
If you were seeing a problem, it was a symptom of something else, and had nothing to do with the dropped frames.
Mencoder also has -noskip, -mc 0, -skiplimit 0, to prevent skiped frames (due to A/V sync issues), and to prevent "duplicate frames" from being dropped, you can use -vf harddup.
why ej: mplayer is a big binary monolith instead of something more modular which can be used by other people.
Speed, speed, and more speed...
Using external libraries incures a performance penalty, so the default is to compile everything static. You can use external versions of most libs if you specify them during configure.
If you want a library, use libavcodec. If you want to use MPlayer, that's exactly what "Slave Mode" is for.
Personally, I love the binary monolith, if only because it keeps me from having to deal with dependency hell...
(and don't even mention the useful but ugly hack that mozplugger is, please).
Okay, I'll mention mplayerplugin then.
Or better yet, something like kmenc15 (http://kmenc15.sourceforge.net/).
No, actually FAST code is preferred to READABLE code.
There's good reason why, when you hear stories about people watching DVDs on their 133MHz systems, they're always using MPlayer...
MPlayer plays MPEG-1/2/4 videos at 720x480 on my 1.6GHz system using LESS THAN 1% CPU TIME. I can play back 1080 videos on this system in realtime with any codec around (h.264 drops a few frames, but that's all).
It's now 8 months later and not even a dev CVS build.
There was a major hardware failure, which took down the main server for several months. Development has continued on CVS, and you can grab a snapshot any time you wish. This hasn't just stopped OS X development. If you were a bit more observant, you'd see there haven't been new releases on the server for ANY architecture for nearly a year.
There are at least 2 MPlayer devs with PPC/OS X machines, who continue to find and fix bugs. I'm sure you'll see new OS X releases soon.
the reason ive heard of is containing of patented stuff if mplayer core that can not be easily modularised.
Yes, pretty much ALL audio and video codecs you've ever heard of, or used are covered by numerous patents which require payment of royalties by the program maker. Companies like RedHat/Suse don't want to pay $10 in license fees for each user which downloads the distro.
It certainly can't be modularized, for performance reasons, nor would you want it to be, as MPlayer with 1 video codec is just as useless as not having MPlayer at all, and perhaps worse, because of people beliving that MPlayer sucks.
It's an idential situation as with Xine, VLC, etc.
oh, another thing... last release has happened in quite some time. what happened to 'release early, release _often_' ?
That's not MPlayer's credo. If you really care, the reason is because of a major hardware failure. The next release is probably only a few days away now, and you can grab latest CVS at any time.
What I found were rather clueless questions, which could have been easily resolved by searching the mailing list for similar problems. And despite all that, you had perhaps a dozen different people posting multiple replies to your messages, giving very useful information without the slightly flaming.
I don't have any idea how you could consider that "newbie bashing".
I use VLC for my IPTV-provider, because RTSP sucks in mplayer (at least for me).
MPlayer uses the live555.com library for RTSP support, which is exactly the same thing VLC uses. Your problems are likely local issues (perhaps a binary package without live555 support?), and not actually problems with MPlayer.
MPlayer also gets its "hands dirty" with DeCSS and WMV "support" in *nix.
DeCSS was a Windows program. The Unix version was css-auth. Shortly after, libdvdcss was reverse-engineered to give legal DVD playback, and that is what has been used by every player (since about 2001, IIRC).
The ironic thing is, not only does VLC support libdvdcss, but libdvdcss was in fact written and maintained BY the VLC team, as you could tell from the fact that the official libdvdcss URL is on their server: http://developers.videolan.org/libdvdcss/
Unfortunately, neither VLC nor MPlayer can be included as libraries in other multimedia applications.
You either don't know what you're talking about, or you're trolling.
No, mplayer can't be used as a library, but most of it's functionality comes directly from ffmpeg/libavcodec, which CAN be used as a library, and IS used by a HUGE number of projects.
It has easy aspect ratio correction, low CPU usage, and key re-mapping, among it's many useful features.
MPlayer has lower CPU usage than any other video player I've ever tried on Windows. It really uses around half the CPU time to play videos as something like MPC does. Frankly, I really don't understand how Windows can be so terrible at multimedia, and why people aren't more upset about something like DVD playback using 50% of their multi-GHz CPU.
As for usability, there are several 3rd party MPlayer GUIs for Windows which make it rather easy to operate.
MPlayer supports arbitrary key remaping beyond any other player out there. You can bind any key to any of ~100 functions the player can perform. You can arbitrarily define how far you want it to seek forward/backward with each key, etc. You can bind a key to change the aspect on-the-fly if you want.
From what I've seen, xine does everything that mplayer does, and more, so why bother.
Xine is much slower, has a terrible interface, supports fewer audio/video codecs, takes longer to get support for newer codecs, doesn't do ANY encoding at all, doesn't support a fraction as many output audio/video devices. Doesn't have a fraction of the great video/audio filters that MPlayer does. Uses far, far more CPU-time than MPlayer. Has a god-awful interface, and no simple command-line version. Murders puppies. Doesn't include options like allowing you to output JPEGs out of every 100ths frame. Doesn't allow you to process the video, then output to yuv4mpeg for encoding with other programs. etc.
The difference between XINE and MPlayer are really the difference between Windows and Unix... Do you want a monolithic program, which can't be scripted, and has many, many restrictions imposed on it, or a small, simple tool that you can script to manipulate and modify data any way you choose?
Major problems like that, always get fixed quickly.
As I said, segfaults are very rare these days. Most of the time segfaults are reported, it's buggy hardware (hot CPU, RAM, videocard, etc.) or a known-buggy version of GCC (2.96, 3.3, etc).
I wonder if they sent some code back to the MPlayer guys for that
No, definately not. MPlayer dvdnav was wholely written by Ötvös Attila (http://dcxx.fw.hu/)
(or perhaps vice versa)?
The dvdnav patch has been publicly available (in it's unstable form) for quite a while now. It's almost certain that the XBMC guys just grabbed the patch and applied it to their sources.
I've plugged the project a few times here on/. before, as I had a very similar myself long before udpp2p existed.
I think it's a real shame development has stopped, as it had the potential to be as fast as any other P2P network, and completely anonymous for the sender. All without requiring extensive communities and webs of trust to decide who to allow full access to your encrypted P2P VPN.
As to the retransmit problems listed on your site, you should really use the Gnutella model, but broadcasting ACKs in this case as well as searches. You can make the window quite large, to form a large list of packets needing resend, and compress that data so it uses up as little bandwidth as possible.
Yeah. You can't imagine my disappointment in the 80's when I bought a ticket to see a technical movie about "binary large objects", only to see NOT ONE computer in the whole movie!
I mean, they even CAPITALIZED "BLOB" to fool people into thinking it was an acronym.
On the contrary. Anything benign, which has is now widely viewed as "hacking" by the minimum-wage fools at large, is something we should get HUGE NUMBERS of people to do, all at once.
The guys upstairs would be mighty unhappy if the residence MSCE decided that 1/4 of all their subscribers were hackers that needed their contracts terminated for port-scanning some public servers...
What service or what architecture that is widely used today is so brain-dead that it does not require a password or strong encryption or some other form of security and/or authentication that would ensure that spoofing the IP address does not constitute a successful attack?
NFS.
Despite the numerous one-off network filesystem projects out there, none of them have caught-on (I believe that's mainly because of licensing) so NFS continues to be used extensively.
People are trying to tack-on different forms of authentication, such as kerberos/knfs, tunneling it over SSH, using something like pf-auth, or using VPNs. Unfortunately, all of the above are quite complex to setup and maintain, and wide-open NFS is still quite common.
Slashdot Mirror
WTF? First off, when did Lead-Acid batteries enter the discussion? You aren't going to have a portable drill with a Lead-Acid battery attached to it.
Second, that PDF doesn't show what sustained loads the batteries can take, only current discharge over time/tempurature, and voltage drop.
Third, the PDF says the EXACT OPPOSITE of everything you are saying in your post! You say NiCD batteries drop power output, while the PDF says:
That matches my direct experience, and everything I've ever read about nickel cadmium and Lead-acid batteries, while your statement is just completely wrong.
This is just completely wrong. NiCADs will provide close to their full voltage/current until they are damn-near completely depleated, and then they will very suddenly dim.
I really can't imagine how you've managed to get NiCAD vs Lead Acid so completely backwards.
Yes, older countries like China, Russia, etc. know better... Whoops, not what you had in-mind, huh?
I guess the more elitist Europeans like yourself don't need any facts to support your claims, either.
Hint: The USA is a big place... bigger than all of Western Europe. In the USA there are different states, where the laws may vary, just like countries in Europe. Some of these states are actually significantly AHEAD of Europe in environmental regulations. In fact California has had a law somewhat similar to this since at least 2000.
I must say, I find it absolutely HILARIOUS that you're using that list to explain your desire to leave Australia for Europe, when Australia is the #3 most livable country according to that list.
Wear sunblock. Plant a few trees. etc.
I'll take the desert, over the freezing North Atlantic, any day.
From the increase in X CPU usage, it sounds like you're perhaps using a junky on-board videochip (or perhaps something with lowsy drivers), or using an output method like x11 instead of one of the many overlay outputs (which hardly even involve X). I'm just using an ultra-cheap, 4 year-old GeForce4 AGP card myself.
Since you're on an AMD64, I wonder if you've compiled it as a 64-bit or a 32-bit binary; if you compiled it yourself or are you using a binary package (runtime CPU-detection blows)? What version of GCC did you use, which version of MPlayer, which kernel version, etc.
Certainly the AMD64 version of MPlayer hasn't gotten nearly as much hand-written assembler optimization as the standard x86 version has, but your performance should still be better...
You're assuming inverse telecine and deinterlacing is CPU-intensive. It can be, with filters like pullup and kerndeint, but most of them, like filmdint, use practically no CPU time at all. So the larger resolution of PAL material may be more of a slowdown than inverse telecine or deinterlacing.
The fact that you aren't getting it, doesn't mean it's not true. I can think of many reasons your CPU usage would be higher than it should be...
Perhaps you're using a large cache value, while -nocache is actually fastest. Perhaps -rtc support is causing a slowdown, and you can use -nortc for a speed-up. Options like "-lavdopts fast" work nicely in most cases as well.
Now WHY would someone do that? Out of spite for the new law? No, I think not.
This requires shops to collect used batteries at NO COST, so I can't see any reason someone would do something as insane as going out of their way to toss it into a river.
Yes, well... Either something is very wrong with your system, you're completely mistaken, or you're just making things up. I find the latter to be most likely.
Posting at +1, UID of almost 900,000, no details or info to back-up your extremely vague claims that fly in the face of all logic.
If you've got files that crash MPlayer and not Xine, upload a sample somewhere so it can be verified.
If MPlayer is insanely slow for some reason, perform some detailed benchmarks with both programs on the same videos, and post the full output somewhere as well. You can send it to the mplayer mailing list as well.
Yes, head is stable, for MPlayer at least.
It's usually okay if you want Mencoder, too, but occasionally a major mencoder bug will slip in and not get fixed for a few days.
Under absolutely ALL circumstances. MPlayer has been heavily optimized for speed, while XINE hasn't. I've never before seen ANYONE claim Xine was EVER faster.
If you're actually seeing something like that, and not just trolling, either you got a poorly made binary package, or you were doing something like using the wrong output method for your system.
Also something I have NEVER heard from ANYONE, ANYWHERE. MPlayer is much more tolerant of errors, and will play far more media types. If you're seeing some bug, you should report it, and perhaps provide a sample.
vidix is faster than XV in just about all cases. gl is faster if your drivers have OpenGL support, and MUCH, MUCH, MUCH faster on HD material.
svga/fbdev support makes it possible to play videos even without X11 installed, and can be faster in some cases.
No, I'm not just talking about encoding. Good inverse telecine filters are absolutely necessary in the US and other NTSC countries. There are plenty of other filters like overlays for interactive on-screen graphic interfaces (eg. Freevo), filters to fix videos which have been improperly encoded, like deinterlacing telecined content, numerous postprocessing filters, filters to remove TV station logos, etc.
No, mencoder only drops exactly identical frames.
If you were seeing a problem, it was a symptom of something else, and had nothing to do with the dropped frames.
Mencoder also has -noskip, -mc 0, -skiplimit 0, to prevent skiped frames (due to A/V sync issues), and to prevent "duplicate frames" from being dropped, you can use -vf harddup.
None of which will fix your problem though.
Speed, speed, and more speed...
Using external libraries incures a performance penalty, so the default is to compile everything static. You can use external versions of most libs if you specify them during configure.
If you want a library, use libavcodec. If you want to use MPlayer, that's exactly what "Slave Mode" is for.
Personally, I love the binary monolith, if only because it keeps me from having to deal with dependency hell...
Okay, I'll mention mplayerplugin then.
Or better yet, something like kmenc15 (http://kmenc15.sourceforge.net/).
Or how about Freevo, or XMMS-MPlayer, or GImageView, or anything else on the Projects page: http://mplayerhq.hu/homepage/design7/projects.htm
And playing back a DVD averages less than 5% of my Athlon XP 2000+ using MPlayer.
No, actually FAST code is preferred to READABLE code.
There's good reason why, when you hear stories about people watching DVDs on their 133MHz systems, they're always using MPlayer...
MPlayer plays MPEG-1/2/4 videos at 720x480 on my 1.6GHz system using LESS THAN 1% CPU TIME. I can play back 1080 videos on this system in realtime with any codec around (h.264 drops a few frames, but that's all).
There was a major hardware failure, which took down the main server for several months. Development has continued on CVS, and you can grab a snapshot any time you wish. This hasn't just stopped OS X development. If you were a bit more observant, you'd see there haven't been new releases on the server for ANY architecture for nearly a year.
There are at least 2 MPlayer devs with PPC/OS X machines, who continue to find and fix bugs. I'm sure you'll see new OS X releases soon.
Yes, pretty much ALL audio and video codecs you've ever heard of, or used are covered by numerous patents which require payment of royalties by the program maker. Companies like RedHat/Suse don't want to pay $10 in license fees for each user which downloads the distro.
It certainly can't be modularized, for performance reasons, nor would you want it to be, as MPlayer with 1 video codec is just as useless as not having MPlayer at all, and perhaps worse, because of people beliving that MPlayer sucks.
It's an idential situation as with Xine, VLC, etc.
That's not MPlayer's credo. If you really care, the reason is because of a major hardware failure. The next release is probably only a few days away now, and you can grab latest CVS at any time.
You've obviously never heard of gmplayer, which is the offical GUI, and comes included with MPlayer.
No, you were probably derided because you were making mistakes very clearly covered in the appropriate section of the docs.
Probably about a dozen deinterlacers, actually.
Since you make it sound like you were brutalized, I decided to go search the archives...
http://thread.gmane.org/gmane.comp.video.mencoder
http://thread.gmane.org/gmane.comp.video.mencoder
http://thread.gmane.org/gmane.comp.video.mencoder
What I found were rather clueless questions, which could have been easily resolved by searching the mailing list for similar problems. And despite all that, you had perhaps a dozen different people posting multiple replies to your messages, giving very useful information without the slightly flaming.
I don't have any idea how you could consider that "newbie bashing".
MPlayer uses the live555.com library for RTSP support, which is exactly the same thing VLC uses. Your problems are likely local issues (perhaps a binary package without live555 support?), and not actually problems with MPlayer.
DeCSS was a Windows program. The Unix version was css-auth. Shortly after, libdvdcss was reverse-engineered to give legal DVD playback, and that is what has been used by every player (since about 2001, IIRC).
The ironic thing is, not only does VLC support libdvdcss, but libdvdcss was in fact written and maintained BY the VLC team, as you could tell from the fact that the official libdvdcss URL is on their server: http://developers.videolan.org/libdvdcss/
You either don't know what you're talking about, or you're trolling.
No, mplayer can't be used as a library, but most of it's functionality comes directly from ffmpeg/libavcodec, which CAN be used as a library, and IS used by a HUGE number of projects.
MPlayer has lower CPU usage than any other video player I've ever tried on Windows. It really uses around half the CPU time to play videos as something like MPC does. Frankly, I really don't understand how Windows can be so terrible at multimedia, and why people aren't more upset about something like DVD playback using 50% of their multi-GHz CPU.
As for usability, there are several 3rd party MPlayer GUIs for Windows which make it rather easy to operate.
MPlayer supports arbitrary key remaping beyond any other player out there. You can bind any key to any of ~100 functions the player can perform. You can arbitrarily define how far you want it to seek forward/backward with each key, etc. You can bind a key to change the aspect on-the-fly if you want.
Xine is much slower, has a terrible interface, supports fewer audio/video codecs, takes longer to get support for newer codecs, doesn't do ANY encoding at all, doesn't support a fraction as many output audio/video devices. Doesn't have a fraction of the great video/audio filters that MPlayer does. Uses far, far more CPU-time than MPlayer. Has a god-awful interface, and no simple command-line version. Murders puppies. Doesn't include options like allowing you to output JPEGs out of every 100ths frame. Doesn't allow you to process the video, then output to yuv4mpeg for encoding with other programs. etc.
The difference between XINE and MPlayer are really the difference between Windows and Unix... Do you want a monolithic program, which can't be scripted, and has many, many restrictions imposed on it, or a small, simple tool that you can script to manipulate and modify data any way you choose?
Segfaults are very, very rare. If you are seeing one, you should report it: http://www.mplayerhq.hu/DOCS/HTML/en/bugreports.h
Major problems like that, always get fixed quickly.
As I said, segfaults are very rare these days. Most of the time segfaults are reported, it's buggy hardware (hot CPU, RAM, videocard, etc.) or a known-buggy version of GCC (2.96, 3.3, etc).
No, definately not. MPlayer dvdnav was wholely written by Ötvös Attila (http://dcxx.fw.hu/)
The dvdnav patch has been publicly available (in it's unstable form) for quite a while now. It's almost certain that the XBMC guys just grabbed the patch and applied it to their sources.
I've plugged the project a few times here on /. before, as I had a very similar myself long before udpp2p existed.
I think it's a real shame development has stopped, as it had the potential to be as fast as any other P2P network, and completely anonymous for the sender. All without requiring extensive communities and webs of trust to decide who to allow full access to your encrypted P2P VPN.
As to the retransmit problems listed on your site, you should really use the Gnutella model, but broadcasting ACKs in this case as well as searches. You can make the window quite large, to form a large list of packets needing resend, and compress that data so it uses up as little bandwidth as possible.
Yeah. You can't imagine my disappointment in the 80's when I bought a ticket to see a technical movie about "binary large objects", only to see NOT ONE computer in the whole movie!
I mean, they even CAPITALIZED "BLOB" to fool people into thinking it was an acronym.
On the contrary. Anything benign, which has is now widely viewed as "hacking" by the minimum-wage fools at large, is something we should get HUGE NUMBERS of people to do, all at once.
The guys upstairs would be mighty unhappy if the residence MSCE decided that 1/4 of all their subscribers were hackers that needed their contracts terminated for port-scanning some public servers...
NFS.
Despite the numerous one-off network filesystem projects out there, none of them have caught-on (I believe that's mainly because of licensing) so NFS continues to be used extensively.
People are trying to tack-on different forms of authentication, such as kerberos/knfs, tunneling it over SSH, using something like pf-auth, or using VPNs. Unfortunately, all of the above are quite complex to setup and maintain, and wide-open NFS is still quite common.