I really didn't want to get into specifics, and waste a bunch of time on minutia in this thread, discussing the pros and cons of each, and details like one not having some edge feature Neat or some other does.
There are oh so many out there, and lots and lots of others have endlessly discussed the benefits of each. There's even new ones every day, because, as the OP said, it's just a matter of a tiny bit of programming to fit all the existing pieces together.
Sadly there is still nothing like the Neat scanner system for Linux. Something that, preferably, OCRs and indexes your documents for easy searching and retrieval. At the least something that indexes, even if you have to manually populate the fields. Nothing at all after years of hoping.
There are NUMEROUS document/content management systems for Linux (and have been for years), any of which will do VASTLY more than the dumbed-down "Neat" system.
No, you asserted that Opera did tabs correctly. Your opinion on the subject has no more weight than mine. Meanwhile, you completely discounted, and failed to explain away the FACT that Opera later directly copied Firefox's tab model (while keeping its old tab method as an option). You also failed to explain why opera's stupid method of cycling tabs in historical order is any better than letting the window manager do it, or how having multiple browser windows tiled inside of the larger Opera window, is EVER a good feature, for ANYONE, in ANY situation, and disallowing multiple full browser windows.
You're free to hold your own opinions, of course. But disagreeing with me, asserting I'm wrong and your opposing opinion is right, without bothering to factually refute ANY of the points I made, just makes you a whiny child crying "nuh uh" over and over again, and nothing more.
Since you don't seem to have the wherewithal to even hold a coherent discussion, I will try to remember to ignore you in the future.
Opera really wasn't the first in most cases, and they implemented the features very POORLY, only to have other browsers eventually come along and show them the right way to do it.
Tabs: Opera was second behind another little known IE shell, and their method of cycling tabs in LAST-USED order, and having those tabs appear as loose windows INSIDE of the Opera window was a nightmare that resembled MS Office 7's multiple open document windows, more than it does modern tabbed browsers. In fact, when Mozilla came out with tabs, OPERA COPIED THEM, so now Opera has TWO completely different methods of handling tabs. What made Mozilla's tabs great was the "open in background" option... With that, I'd be perfectly happy managing dozens of windows. It was the "new windows" opening in the foreground and having to be moved that was the real hassle, and the innovation.
Pop-up blocking: Worked poorly in Opera. It blocked the majority of popups, but several still got through, and in the process it broke plenty of legit sites. Mozilla did it right. And everybody and their mother thought up pop-up blocking long before Opera or anyone else did it... The devil is in the implementation details.
Fit to Window: I was crying, loudly, in public forums, for this feature on my PDA for YEARS and YEARS before Opera released it. Their implementation was over simplistic, more like disabling style sheets or removing the "<table" tags than what we use today. So they don't get credit for implementing the current smartphone browser zoom and fit-to-width methods (which do things much differently).
If you're looking for inexpensive and simple, you should consider Google's Ganeti.
Google uses it pretty heavily in their offices. It's simple to manage (command-line) and has some unique features, like being based on DRBD so it uses local storage and doesn't need anything like a SAN, and reads (but not writes) going as fast as local storage, rather than bottlenecked by the interconnect you're using.
See the interesting hour-long speech about how they're using it, available in MP4 and WebM:
1. Users are NOT familiar with the Windows UI. The UI changes every damn release, in substantial ways, requiring retraining or lots of trial and error. Ironically, Windows 7 with its new large task bar and large icons, looks almost exactly like my GNOME 0.9x desktop on Slackware Linux 3.x, circa 1996.
2. Windows has a lot of software to fill in missing pieces and fix broken-ness of the OS, which are entirely unnecessary in other OSes. You bet, Windows has a lot of disk defragmenter programs, and Linux has practically none, but that's not a bad thing. FOSS software has reached a point that damn near anything you could want on Windows, can be done on any other OS as well, and usually BETTER.
3. I'll concede games, though I, and I believe most people, prefer bypassing the topic, and using a game console instead. PC gaming was a big deal back in the 90s, but these days consoles are just as capable, games are as good if not better and cheaper all-around.
4. OpenOffice and LibreOffice are superb. With Microsoft's absolutely moronic switch to the "ribbon" interface, I find MS Office to be the second-class citizen... the also-ran that I avoid if humanly possible. MS Office is now the crippled knock-off version, where there are tons of things users want to do, but can't figure out how to do, to save their life.
North Korea could pretty easily launch a nuclear weapon right into downtown Seoul and kill half a million people
Their nuclear weapons are on-par with larger conventional bombs, so you're not going to get remotely that many dead by any stretch of the imagination. Besides, you're assuming their rockets wouldn't explode 10 seconds after leaving the launch pad, and that it would actually come down somewhere near where they aimed it, which isn't a foregone conclusion.
Certainly, we have to be worried that they'd get a lucky shot off, and kill many thousands before anyone could respond, but they're not as much of a threat as you make it out to be.
while launching a war that will kill a million more.
The US would take just a few hours to set-up some weapon systems that would vaporize any object found moving along the DMZ, and a few sorties to eliminate all NK air offense and defense, as well as artillery installations.
Then again, maybe I misunderstood. If you meant those numbers reflect the scores of North Korean casualties, then maybe you're correct after all.
one really big consumer of CPU cycles online is encryption
No. On modern computers, encryption is insignificant. A single core, 2GHz Pentium M CPU would need less than 1 minute of CPU time to AES encrypt/decrypt your 4GB, 100+ minute video stream (working out to a nice round 1%). And if your CPU is newer, it might even be offloaded to the AES-NI instruction set, making it more than an order of magnitude faster still.
Solaris runs on x86 indeed, but the pricing will kill you, and is such that it makes SPARC servers nearly free if you need Solaris.
I actually know Solaris fairly well, and it has its strong points, but I can't say the same for SPARC hardware. Oracle and IBM have fared somewhat better than HP (who are dragging out the slow death of the Itanium) but the downfall of proprietary platforms and vendor lock-in, is on the horizon. They just can't compete. SPARC machines used to dominate the top ranks of the TOP500 list, but now they are barely represented. There is no future for SPARC servers in a decade.
You can run Linux on SPARC, don't know why you would want to though, Solaris is very good. No, it's not Linux, but it's still very good.
Right there, you're tacitly admitting that there's nothing worthwhile about Oracle's SPARC hardware. If it was faster, or cheaper, or one of the above for some subset of tasks, there would be a huge number of reasons you might want to run Linux on them. Linux is sufficiently cross-platform that moving workloads from x64 to SPARC would be reasonably easy, while porting everything to SPARC would be far more difficult. But you're right, nobody would ever do something crazy like that, because SPARC hardware can't compete with x64.
By dismissing Linux on SPARC, you're just saying what all of us already knew... That SPARC's only selling point is that it runs Solaris, and has legacy application compatibility.
Funny thing is, just a couple days ago I was reading a presentation about the obscene amounts of money MorganStanley was saving by switching their OpenAFS cluster from Linux over to Solaris on SPARC.
The advantages are mostly around ZFS, plus dedupe and compression, but they throw in DTrace as well, as having helped track down performance issues with OpenAFS.
This is decidedly one place where Linux is lagging massively behind. Linux could eventually catch up, but only if Oracle sits on their ass and doesn't keep improving things (which I expect they wont). FreeBSD seems like the only alternative, but ZFS on FreeBSD lags behind in features, performance, and stability, so Solaris could stay king if Oracle kept throwing money into it (which they won't). FreeBSD also doesn't have the benefit of being built for only one vendor's hardware, so it can have just one set of drivers built-in and heavily tested and documented.
The Oracle/HP lawsuit left both sides hurting. HP may have a âoeMilkâ the Customer Business Strategy but I'd argue ALL proprietary Unix system vendors, including Oracle, have been doing EXACTLY the same thing ever since AMD's Opteron came out, and brought the end in sight. HP, Oracle, and IBM will continue squeezing the last drops of life out of whatever hardware improvements were already in the pipeline, then just act as rent-seekers, offering maintenance on all those legacy boxes, until the economics makes migrating all those legacy applications to Linux, unavoidable.
Here's a crazy question... Are the lower (white-space) frequencies really worth all the efforts? We're talking about UHF TV frequencies here, which generally only go up to 60 miles, really only slightly beyond line-of-sight (VHF can do quite a bit better). Outside of heavily wooded forests and dense urban cities, how much benefit are they getting out of these frequencies, versus needing to site their WiFi antennas better (ie. higher up), or having twice as many base stations repeating the signal?
Is the benefit of slightly better range with the lower frequencies really worth buying custom equipment, rather than commodity $35 off-the-shelf APs? Neither the stories on Google or Microsoft's efforts with this tech actually say a non-trivial amount about the tech.
for VP8 to be free they still need to be invalidated individually in many courts around the world
The EU doesn't enforce software patents in the first place, so there shouldn't be a problem with a WebRTC codec. it's only when implemented in dedicated hardware that the patents might be a concern, and enforcement on that is rare and contentious.
And Google isn't going to be too concerned if VP8 is patent encumbered in Trinidad.
Even at 256 kbps, highhats tend to sound like they're being hit with a bag of broken glass, and is the easiest way to identify lossy compression I can think of.
You're not identifying "lossy compression", instead you're actually identifying frequency-domain lossy compression. If you try the same test with a time domain lossy codec like Musepack or even MPEG-1 Layer II (MP2) at high bitrates you won't get the distortion, and you'll be unable to tell the original from the lossy compressed sample.
Modern lossy codec research (HE-AACv2 SBR, Opus, etc) is focused on very low bitrate encoding, NOT transparency. We had transparency with the first international standard audio codec (MP2) and Musepack improved greatly upon that. Strangely, somehow we ended up with those low bitrate codecs (AAC, MP3, Vorbis) becoming the standard for high bitrate (192k+) encoding, where they do a very poor job, and are easily beaten by the earlier, simpler codecs.
And try Musepack or Layer2 on something extremely tonal like harpsichord or (to a lesser extent) 12-string acoustic guitar.
It'll still work fine, it's just not the most efficient. But with that really only matters with streaming these days.
There's no question temporal domain codecs aren't the best at low-bitrate coding, but at high bitrates (192k+), which are commonly used for music downloads, CD rips, etc., they do a far better job than the more common codecs, and it's very strange how we ended up with the most ill-suited codecs being used far outside of their niche.
And there's always the option of a hybrid like AC3... What do you say about merging Opus and Musepack? It's free. You've already got CELT+SILK, what's one more coder?... *cough*
For portables, 256kbps AAC seems to do the least amount of damage.
Try your test track with Musepack or MPEG-1 Layer2 (MP2). There's a world of difference between those two temporal domain codecs, and common frequency domain codes like MP3, AAC, Vorbis, Opus, etc.
It depends on a variety of factors, most notably the content, the codec, the bitrate, and the playback.
The constraints of the question are pretty well defined. We're talking about popular music, with common codecs at bitrates used by online music stores.
No you can't. Not with any reasonably modern encoder and bitrates above 256. Anyone who tells you otherwise is experiencing the placbo effect.
All frequency-domain lossy audio codecs (MP3, AAC, Ogg/Vorbis, others) have inherent limitations that prevent transparent reproduction of audio. Transients will be poorly reproduced, and artifacts like pre-echo are unavoidable.
2+2 does not equal 5. The sky is not green. Water is not dry. Your assertion is wrong, and based in total ignorance of the topic.
Slashdot Mirror
I really didn't want to get into specifics, and waste a bunch of time on minutia in this thread, discussing the pros and cons of each, and details like one not having some edge feature Neat or some other does.
http://lmgtfy.com/?q=linux+document+management+system
There are oh so many out there, and lots and lots of others have endlessly discussed the benefits of each. There's even new ones every day, because, as the OP said, it's just a matter of a tiny bit of programming to fit all the existing pieces together.
There are NUMEROUS document/content management systems for Linux (and have been for years), any of which will do VASTLY more than the dumbed-down "Neat" system.
No, you asserted that Opera did tabs correctly. Your opinion on the subject has no more weight than mine. Meanwhile, you completely discounted, and failed to explain away the FACT that Opera later directly copied Firefox's tab model (while keeping its old tab method as an option). You also failed to explain why opera's stupid method of cycling tabs in historical order is any better than letting the window manager do it, or how having multiple browser windows tiled inside of the larger Opera window, is EVER a good feature, for ANYONE, in ANY situation, and disallowing multiple full browser windows.
You're free to hold your own opinions, of course. But disagreeing with me, asserting I'm wrong and your opposing opinion is right, without bothering to factually refute ANY of the points I made, just makes you a whiny child crying "nuh uh" over and over again, and nothing more.
Since you don't seem to have the wherewithal to even hold a coherent discussion, I will try to remember to ignore you in the future.
"Nuh uh" is not a rebuttal... I was there through the years, trying to use Opera. It sucked, for all the reasons I listed.
If I was wrong, Opera would have a vastly larger user-base today, instead of being a tiny also-ran.
Opera really wasn't the first in most cases, and they implemented the features very POORLY, only to have other browsers eventually come along and show them the right way to do it.
Tabs: Opera was second behind another little known IE shell, and their method of cycling tabs in LAST-USED order, and having those tabs appear as loose windows INSIDE of the Opera window was a nightmare that resembled MS Office 7's multiple open document windows, more than it does modern tabbed browsers. In fact, when Mozilla came out with tabs, OPERA COPIED THEM, so now Opera has TWO completely different methods of handling tabs. What made Mozilla's tabs great was the "open in background" option... With that, I'd be perfectly happy managing dozens of windows. It was the "new windows" opening in the foreground and having to be moved that was the real hassle, and the innovation.
Pop-up blocking: Worked poorly in Opera. It blocked the majority of popups, but several still got through, and in the process it broke plenty of legit sites. Mozilla did it right. And everybody and their mother thought up pop-up blocking long before Opera or anyone else did it... The devil is in the implementation details.
Fit to Window: I was crying, loudly, in public forums, for this feature on my PDA for YEARS and YEARS before Opera released it. Their implementation was over simplistic, more like disabling style sheets or removing the "<table" tags than what we use today. So they don't get credit for implementing the current smartphone browser zoom and fit-to-width methods (which do things much differently).
If you're looking for inexpensive and simple, you should consider Google's Ganeti.
Google uses it pretty heavily in their offices. It's simple to manage (command-line) and has some unique features, like being based on DRBD so it uses local storage and doesn't need anything like a SAN, and reads (but not writes) going as fast as local storage, rather than bottlenecked by the interconnect you're using.
See the interesting hour-long speech about how they're using it, available in MP4 and WebM:
https://www.usenix.org/conference/lisa12/ganeti-your-private-virtualization-cloud-way-google-does-it
Or just the PDF of the slideshow: http://whatexit.org/tal/PICC12/Ganeti-90.pdf
1. Users are NOT familiar with the Windows UI. The UI changes every damn release, in substantial ways, requiring retraining or lots of trial and error. Ironically, Windows 7 with its new large task bar and large icons, looks almost exactly like my GNOME 0.9x desktop on Slackware Linux 3.x, circa 1996.
2. Windows has a lot of software to fill in missing pieces and fix broken-ness of the OS, which are entirely unnecessary in other OSes. You bet, Windows has a lot of disk defragmenter programs, and Linux has practically none, but that's not a bad thing. FOSS software has reached a point that damn near anything you could want on Windows, can be done on any other OS as well, and usually BETTER.
3. I'll concede games, though I, and I believe most people, prefer bypassing the topic, and using a game console instead. PC gaming was a big deal back in the 90s, but these days consoles are just as capable, games are as good if not better and cheaper all-around.
4. OpenOffice and LibreOffice are superb. With Microsoft's absolutely moronic switch to the "ribbon" interface, I find MS Office to be the second-class citizen... the also-ran that I avoid if humanly possible. MS Office is now the crippled knock-off version, where there are tons of things users want to do, but can't figure out how to do, to save their life.
Their nuclear weapons are on-par with larger conventional bombs, so you're not going to get remotely that many dead by any stretch of the imagination. Besides, you're assuming their rockets wouldn't explode 10 seconds after leaving the launch pad, and that it would actually come down somewhere near where they aimed it, which isn't a foregone conclusion.
Certainly, we have to be worried that they'd get a lucky shot off, and kill many thousands before anyone could respond, but they're not as much of a threat as you make it out to be.
The US would take just a few hours to set-up some weapon systems that would vaporize any object found moving along the DMZ, and a few sorties to eliminate all NK air offense and defense, as well as artillery installations.
Then again, maybe I misunderstood. If you meant those numbers reflect the scores of North Korean casualties, then maybe you're correct after all.
No. On modern computers, encryption is insignificant. A single core, 2GHz Pentium M CPU would need less than 1 minute of CPU time to AES encrypt/decrypt your 4GB, 100+ minute video stream (working out to a nice round 1%). And if your CPU is newer, it might even be offloaded to the AES-NI instruction set, making it more than an order of magnitude faster still.
Solaris runs on x86 indeed, but the pricing will kill you, and is such that it makes SPARC servers nearly free if you need Solaris.
I actually know Solaris fairly well, and it has its strong points, but I can't say the same for SPARC hardware. Oracle and IBM have fared somewhat better than HP (who are dragging out the slow death of the Itanium) but the downfall of proprietary platforms and vendor lock-in, is on the horizon. They just can't compete. SPARC machines used to dominate the top ranks of the TOP500 list, but now they are barely represented. There is no future for SPARC servers in a decade.
Right there, you're tacitly admitting that there's nothing worthwhile about Oracle's SPARC hardware. If it was faster, or cheaper, or one of the above for some subset of tasks, there would be a huge number of reasons you might want to run Linux on them. Linux is sufficiently cross-platform that moving workloads from x64 to SPARC would be reasonably easy, while porting everything to SPARC would be far more difficult. But you're right, nobody would ever do something crazy like that, because SPARC hardware can't compete with x64.
By dismissing Linux on SPARC, you're just saying what all of us already knew... That SPARC's only selling point is that it runs Solaris, and has legacy application compatibility.
Funny thing is, just a couple days ago I was reading a presentation about the obscene amounts of money MorganStanley was saving by switching their OpenAFS cluster from Linux over to Solaris on SPARC.
The advantages are mostly around ZFS, plus dedupe and compression, but they throw in DTrace as well, as having helped track down performance issues with OpenAFS.
http://www.ukoug.org/what-we-offer/library/openafs-on-solaris-11-x86-robert-milkowski/
This is decidedly one place where Linux is lagging massively behind. Linux could eventually catch up, but only if Oracle sits on their ass and doesn't keep improving things (which I expect they wont). FreeBSD seems like the only alternative, but ZFS on FreeBSD lags behind in features, performance, and stability, so Solaris could stay king if Oracle kept throwing money into it (which they won't). FreeBSD also doesn't have the benefit of being built for only one vendor's hardware, so it can have just one set of drivers built-in and heavily tested and documented.
The Oracle/HP lawsuit left both sides hurting. HP may have a âoeMilkâ the Customer Business Strategy but I'd argue ALL proprietary Unix system vendors, including Oracle, have been doing EXACTLY the same thing ever since AMD's Opteron came out, and brought the end in sight. HP, Oracle, and IBM will continue squeezing the last drops of life out of whatever hardware improvements were already in the pipeline, then just act as rent-seekers, offering maintenance on all those legacy boxes, until the economics makes migrating all those legacy applications to Linux, unavoidable.
Here's a crazy question... Are the lower (white-space) frequencies really worth all the efforts? We're talking about UHF TV frequencies here, which generally only go up to 60 miles, really only slightly beyond line-of-sight (VHF can do quite a bit better). Outside of heavily wooded forests and dense urban cities, how much benefit are they getting out of these frequencies, versus needing to site their WiFi antennas better (ie. higher up), or having twice as many base stations repeating the signal?
Is the benefit of slightly better range with the lower frequencies really worth buying custom equipment, rather than commodity $35 off-the-shelf APs? Neither the stories on Google or Microsoft's efforts with this tech actually say a non-trivial amount about the tech.
Windows 7 allows the running of X11 graphics through an X server, too!
Thanks Xming and Cygwin developers!
They're grafting big damn camera lenses onto the outside of tiny phones...
http://hugin.info/3009/I/1589087/18258.jpg
The EU doesn't enforce software patents in the first place, so there shouldn't be a problem with a WebRTC codec. it's only when implemented in dedicated hardware that the patents might be a concern, and enforcement on that is rare and contentious.
And Google isn't going to be too concerned if VP8 is patent encumbered in Trinidad.
You're not identifying "lossy compression", instead you're actually identifying frequency-domain lossy compression. If you try the same test with a time domain lossy codec like Musepack or even MPEG-1 Layer II (MP2) at high bitrates you won't get the distortion, and you'll be unable to tell the original from the lossy compressed sample.
http://en.wikipedia.org/wiki/MPEG-1#Quality
Modern lossy codec research (HE-AACv2 SBR, Opus, etc) is focused on very low bitrate encoding, NOT transparency. We had transparency with the first international standard audio codec (MP2) and Musepack improved greatly upon that. Strangely, somehow we ended up with those low bitrate codecs (AAC, MP3, Vorbis) becoming the standard for high bitrate (192k+) encoding, where they do a very poor job, and are easily beaten by the earlier, simpler codecs.
It'll still work fine, it's just not the most efficient. But with that really only matters with streaming these days.
There's no question temporal domain codecs aren't the best at low-bitrate coding, but at high bitrates (192k+), which are commonly used for music downloads, CD rips, etc., they do a far better job than the more common codecs, and it's very strange how we ended up with the most ill-suited codecs being used far outside of their niche.
And there's always the option of a hybrid like AC3... What do you say about merging Opus and Musepack? It's free. You've already got CELT+SILK, what's one more coder? ... *cough*
No comparison to the Pentium Pro CPUs that came on the scene just a few years later, and then became the Xeon line. Socket 8 was mind-bogglingly huge.
Find the data for yourself. I don't take orders. There's tons of research out there, and it's not hard to find, and always getting easier.
You're the one who started off by making baseless bald-faced assertions. I'll leave the onus with you.
Try your test track with Musepack or MPEG-1 Layer2 (MP2). There's a world of difference between those two temporal domain codecs, and common frequency domain codes like MP3, AAC, Vorbis, Opus, etc.
What assumptions? Sounds like you didn't bother reading past the TITLE of TFA. This is spelled-out in the FIRST SENTENCE of the /. summary:
Not true at all. The physics of human hearing is extremely clear. And I really don't care if you want to be a flat-earther and refuse to believe it.
The constraints of the question are pretty well defined. We're talking about popular music, with common codecs at bitrates used by online music stores.
All frequency-domain lossy audio codecs (MP3, AAC, Ogg/Vorbis, others) have inherent limitations that prevent transparent reproduction of audio. Transients will be poorly reproduced, and artifacts like pre-echo are unavoidable.
2+2 does not equal 5. The sky is not green. Water is not dry. Your assertion is wrong, and based in total ignorance of the topic.