Slashdot Mirror

There are NOT a lot of choices of languages when it comes to that.

Not true. In addition to Objective C and Swift you can program for iOS in, for example, Object Pascal or C++ or C# or JavaScript.

Not true indeed. You and I have a huge difference in what "a lot" means. A lot of difference.

There are NOT a lot of choices of languages when it comes to that.

Not true. In addition to Objective C and Swift you can program for iOS in, for example, Object Pascal or C++ or C# or JavaScript.

Look into how HDFS works it's the filesystem underlying Hadoop.

You're not old or wrong. The hipsters just discovered UNIX pipes/sockets and decided that they should give them a trendy name... I shit you not, meet etcd (to be fair, it's pipes with a few extras, but nothing worthy of a name because I guarantee this has been done in the last 40 years once or twice). https://www.youtube.com/watch?...

This is actually the problem I have with Design Patterns - not them in and of themselves; I don't think they needed names, but I'm okay with them having names. I came to figure out Inversion of Control in college before I knew it was a thing. Having common terminology doesn't hurt, but lately it's gone too far. The problem is that someone, somewhere decided that this idea could apply to EVERYTHING. Then we get Enterprise Design Patterns (hello, Spring, OSGI, Blueprints, etc. - each a very specific thing that is so incredibly abstract as if to mock the very idea of naming conventions), Enterprise Cloud Design Patterns, etc. An "Enterprise Cloud Design Pattern" used to be called a topology and they could be expressed in terms of their layout (star, bus, hub and spoke, etc) in terms everyone understood and was comfortable with. Adding virtual machines and "cloud" and load balancers doesn't change the fact that it's a star topology with redundant load balancers in front of it. You don't need a specific term for that.

Now, allow me to rant for a second... Related to the point, the worst quality software I've seen lately describes what it does in these terms. For instance, if you weren't familiar with J2EE, would you ever know what Karaf ( http://karaf.apache.org/ ) is? Don't bother looking for answers in the documentation, because it's sparse and often incorrect when not hand-wavy. I spent a day trying to just get the web interface up to launch something in Karaf (since they recommend that) only to find that "just launch the thing and then open your browser" isn't the way you launch something and you can't access it from your browser. I couldn't get to step two of the documentation that I had to look in Google caches for because their own links to the 2.4 documentation are dead. That's the version that the current version of OpenNMS ships, and they actually changed the command "features:xyz" to "feature:xyz" just so the only documentation where they got their links right is effectively useless until you figure out why nothing works.

• 1. Don't allow users to define their own file names, or if you do, massively restrict the format to alphanumerics and a single dot png|jpg|gif extension.
• 2. Set the directory where uploaded files are stored to NOT execute any scripts, so even if everything else fails and some how a script gets in there, it still can't be executed
• 3. Consider not keeping uploaded files in publicly accessible directories. Instead, use a script as a proxy to read those files and serve them with a specific mime type. Thus Apache won't try to execute them and you can be certain what mime-types are being served

• 4. Be super careful when the file is uploaded that you don't move it into a public directory BEFORE you validate it otherwise there might be a brief window to try to execute it.

And lastly, don't leave anything to chance. This is a really risky area that a lot of people screw up! Never be complacent. Always revisit it. Don't rely on server configuration to be correct because it's too easy to set things up, then move/rebuild a server, and then find you're vulnerable. You need multiple layers of defence.

I have a question to any who anyone who knows - why doesn't Apache demand that PHP scripts have their execute bit set? Because it seems to me that would help quite a bit.

• 1. Don't allow users to define their own file names, or if you do, massively restrict the format to alphanumerics and a single dot png|jpg|gif extension.
• 2. Set the directory where uploaded files are stored to NOT execute any scripts, so even if everything else fails and some how a script gets in there, it still can't be executed
• 3. Consider not keeping uploaded files in publicly accessible directories. Instead, use a script as a proxy to read those files and serve them with a specific mime type. Thus Apache won't try to execute them and you can be certain what mime-types are being served

• 4. Be super careful when the file is uploaded that you don't move it into a public directory BEFORE you validate it otherwise there might be a brief window to try to execute it.

And lastly, don't leave anything to chance. This is a really risky area that a lot of people screw up! Never be complacent. Always revisit it. Don't rely on server configuration to be correct because it's too easy to set things up, then move/rebuild a server, and then find you're vulnerable. You need multiple layers of defence.

I have a question to any who anyone who knows - why doesn't Apache demand that PHP scripts have their execute bit set? Because it seems to me that would help quite a bit.

It was pretty darn hard to parse that article to understand what library the author was talking about, but after some research, the issue seems to be a vulnerability in the Apache Commons Collections library.

I don't understand why the OP calls it "Java commons" or why the author of the article goes out of his way to not mention the name "Apache", using it only when copying and pasting code lines but never stating it in prose. Sure, there are lots of people who may have Java, but if the security vulnerability is of the magnitude that is claimed, properly identifying where it is located would be the logical first step.

There is a somewhat better article at InfoQ.com that parses out the original article and describes it more clearly.

We were corrected by Mr. Frohoff that said the vulnerability is in how developers treat user-supplied serialized data, and not the library itself.

http://news.softpedia.com/news/the-vulnerability-that-will-rock-the-entire-java-world-495840.shtml

This is an issue with how some users use a 3rd party library Apache Commons Collections. Java doesn't have to be fixed. And Apache Commons-Collection doesn't have to be fixed, except maybe stating the obvious...

Do not deserialize objects with executable code from the internet.

I agree. It's terrifying (well, more disappointing) that completely unsubstantiated claims from someone who was chatting anonymously on IRC are being taken seriously by anyone,

Well if it's fake, it's a long con. Especially after you start seeing all this stuff right?

http://protege.stanford.edu/ Java Desktop Application.,Used to define/manage ontologies. Not sure if they have a web version meanwhile and if comes close to what you need. However it supports plugins, perhaps the frontend can be adapted to access a centralized DB. Oh, found it: http://semanticweb.org/wiki/We...égé.html

This is a info page with an overview about various tools: https://en.wikipedia.org/wiki/...

Did you stumble over this: http://www.w3.org/2001/sw/wiki...? Dozens of various tools mentioned.

Another tool, I stumbled iver, but did not use it yet: http://oboedit.org/

And then there is https://jena.apache.org/docume...
But that is more a programming API to dynamically create classes to store/manage data in an ontology described database. (Did not use it yet, but looks promizing)

And then we have this: http://semanticweb.org/wiki/To...

BTW, I can offer remote programming/assistance in such tools.

It's unclear whether most of the FUD in this discussion is directed at the GPL itself or specifically v3. But it's entirely unfounded.

It's not FUD, and its about the GPL in general - although being GPL3 makes it worse. "GPL2 or later" would have been a better (but still flawed) choice.

You know why libraries aren't generally licensed GPL, right? Anything that links to them has to have the exact same license as the library. For instance, the GPL2 licensed Inkscape can't use this library.

That's the difference between the GPL and the LGPL. You can link to LGPL libraries from any software; you can only link to GPL licensed libraries from code with the same version of the GPL.

In RMS' ideal world, all software would move to the latest GPL and it wouldn't be a problem. Good luck convincing these guys of that.

This is the appropriate license for this image format.

The GPL is not the appropriate license for any general-purpose library. That's what the LGPL is for. Or, like most reference implementations, a non-copyleft license like the MIT license.

Look, I get it, you're a promoter of software freedom. So am I. But this is the real world, and this is a reference implementation. There are conventions to follow for reference implementations, and an OSS non-copyleft license is one of those conventions. This image format could outperform every other format on the planet and it will still see no adoption outside of academia unless there's a compatibly licensed library available. Unless it gets relicensed, or someone writes a non-GPL library, this will go down as just another interesting format that sees no adoption whatsoever.

I for my part I'm waiting for a Lucene rewrite, regardless in what language.

Wait no longer. There is a rewrite in C++ called CLucene and another (not as mature) rewrite in pure C called Lucy.

I wrote about this on reddit only recently ... Link to the discussion there

Copied in full to here:

So back when Sun maintained OpenOffice.org and sold StarOffice they had a Contributor License Agreement that required handing over ownership of patches to them so they could sell the closed source supported suite and license out to IBM for Symphony.

To get around this bureaucracy and to not sign over ownership for patches most distributions used go-oo.org (aka ooo-build) that was the source code of OpenOffice.org with a bunch of patches on top to help compatibility with MS Office and some other things that Sun could or did not want in the upstream oo.org code.

When Oracle bought Sun they left oo.org languishing with no maintenance for months. This was naturally unacceptable to the various linux distros and they didn't want to be beholden to Oracle's whims (for good reason given the state of the various projects that used to be with Sun). Due to this they got together and formed The Document Foundation and took the go-oo.org code (which was basically what this group used and collaborated on anyway) and forked it to LibreOffice.

Fast forward some more time and Oracle decide they don't want anything to do with OpenOffice.org after all and essentially (with IBM's help ... presumably so there would be a sort of maintained base for Symphony) dumped it on the Apache Software Foundation. As per their requirements it went through an incubation process and all the code was relicensed to the Apache Public License. This was months after LibreOffice had been created and worked on and most consider it a pretty petty move rather than giving the brand to TDF to work with.

From that point on it's pretty much been IBM driving Apache OpenOffice (as they renamed oo.org to) although they appear to have stopped caring about it mid to end last year. The amount of development work on AOO is minimal compared to LO and the number of active committers is in the teens (at best) for AOO compared to the hundreds for LO.

Due to the way the licensing works out LO can merge in any fixes (there were some in the early days, not many now as can be seen in the CVE issue I mentioned) but AOO cannot merge in work from LO.

The last release of AOO was August 2014 and if you go look at the changelogs from 3.4 (the first AOO release as opposed to oo.org IIRC... mostly rebranding) up to the 4.1.1 then you'll see there's been minimal work - mostly translations. Anything developed/fixed in AOO is either merged into LO or improved/obsoleted by other work. Compare these to the release notes for each LO release from the forking point of 3.3 and it really is quite significant - the heavy work on clean up and better build systems for LO lower the barrier to entry for LO contribution by the common person too.

The proposed AOO release of 4.1.2 is going forwards at the moment - driven mostly by only a few people Apache OpenOffice Dev mail archives.

To give an idea how bad this has got the no-interaction code execution as privileges of user bug by a special HWP file was announced publicly last April. It was fixed in LibreOffice the same month and users would have had the update notification and been protected. Anyone using Apache OpenOffice is still vulnerable and although there was a disclosure on the security part of the AOO site at the time, the workaround was to 'delete .dll/.so' ... not a release with a fix and unless anyone actively went to check up on this they would not have known the issue.

To add to this (if it's not enough already) AOO can still only read and not write docx/xlsx/pptx (OOXML) files produced by MS Office whereas LibreOffice can

one command that comes to mind is: grep.

O(n).

If you want an index use Lucene.

So now you're recommending that the server administrator install the Java virtual machine, which is listed on the front page of Lucene's site as one of Lucene's dependencies, as a means of avoiding use of SQLite. Oracle's legal shenanigans aside, I was under the impression that switching to a plan that includes Java support was unaffordable to a lot of shared hosting customers.

in the 90's, php's only competitor for doing what it could do was embperl.

Where can I download the source for HTTP?

One well-known HTTP server is Apache HTTP Server. You can find source code and Windows binaries at Apache's web site. Apache also offers HttpComponents, which implements the client side of an HTTP connection.

Where can I download the source for HTTP?

One well-known HTTP server is Apache HTTP Server. You can find source code and Windows binaries at Apache's web site. Apache also offers HttpComponents, which implements the client side of an HTTP connection.

Exactly. Having used Java in an enterprise setting for many years, and having had the good fortune to move to Python, I couldn't be happier. I realised how much more verbose Java was than its Python equivalent. Even if you overlook that - there's an inherent structural complexity that Java engenders to its code - one only need look at the Python equivalent to see why. For example, take a look at a basic Hadoop WordCount example here: http://wiki.apache.org/hadoop/... Now compare a rough Python equivalent here: http://mrjob.readthedocs.org/e...

It's not just stuff like the lack of lambdas (it looks like Java 8 has fixed this), or the static typing that contributes to this complexity. I suspect that the culture that has sprung up around Java favours over-architecting and over-engineering, which is exacerbated by its statically typed nature. The Java language itself is simple enough.

In contrast, there is a cult of simplicity around Python, and the language itself has a high-level of expressivity, allowing for a clearer exposition of one's intent - instead of burying it in layer upon layer of abstraction built to please the language and its type system. C# is a language that fares much better than Java in this regard - it's a lot cleaner. For starters - no type erasure!

worth a look too:

https://tika.apache.org/

Then you've got hybrid systems like Cordova. Code your UI and logic in HTML5, use native plugins with javascript interfaces to access the more unusual stuff.

Just saw a remarkable first hand report of people driving donkey carts in the outback of Timbuktu while using cell phones to broker deals on their goods while still hours away from the market.

Good example of capitalism and free enterprise at it's finest. Not sure what it has to do with Wall Street or FOSS though.

It's using this: http://cordova.apache.org/ (via https://msdn.microsoft.com/en-...

Not even that. You can't do generalised virtual hosting with SSL.

The host header is just a header like any other so the server can't figure out which certificate to use to set up the encryption layer. It is possible to do it in a restricted set of circumstances with a wild card certificate that matches all of the virtual hosts.

Java 7 introduced the Closeable interface and try-with-resources statement to give the programmer every incentive to Do The Right Thing in cases like these, and every good Java programmer I know uses them (see http://mina.apache.org/sshd-pr... for topical example of an SSH client implementing Closeable). True, anyone can code badly but that's not the language's fault and in this case I would hardly say that sloppy mentality is encouraged. A poster above noted that C++98 != C++14. By the same token, Java 1.8 != Java 1.2

Nope, it's not.

Come back when it has things like Outline View, first requested oooh about 13yrs ago ( https://bz.apache.org/ooo/show... ), been highest voted or second highest bug/request ever since, but not fixed in 13yrs (apparently it required some reworking of the architecture, and apparently this was done back in 2010...). Having a equivalent of Normal View is also highly voted - I don't use that as much but I can see that if you work on certain types of document layouts it would be essential.

Track changes also lags MS Office significantly.

Excel removed ridiculously low row/column limits almost a decade ago, LO will still only do 1024 columns AFAIK - again, apparently fixing this is too hard. I might only need that for a handful of spreadsheets, but if I have to buy Office anyway for those cases, why would I also use LO and have to master two different tools when I can use Office for everything.

Trouble with OO/LO is similar to electric cars, 80/20 or 90/10 is not a success (against an incumbent tech), it's a problem - if OO/LO can do 90% of my documents or even 95%, I still need Office for the other ones. Similarly if range & charging have improved so that the electric car can do 90% of my journeys or even 95%, that's great - but I still need a fossil fuel car for the others. If I have to have two cars, or two Office suites, instead of one then the new one needs to offer something really compelling that the incumbent doesn't have - and OO/LO doesn't, for me, yet.

I agree that Apache web server support is vital if HTTP/2 is to get much use. That said, the mod_spdy plug-in for Apache supports SPDY, and has been accepted into Apache trunk. See: http://googledevelopers.blogsp... https://svn.apache.org/viewvc/...

Since HTTP/2 is based on SPDY, it seems likely that this plug-in will be tweaked to support HTTP/2. That said, I suspect the Apache Foundation would say something like, "patches welcome".

Flink is a parallel data processing engine similar to Hadoop and Spark with some unique features: 1) combines realtime stream and batch processing, 2) features an DBMS-style optimizer, 3) in-memory processing which goes gracefully to disk if memory is scarce, 4) provides special operators for iterative processing, ... Check out http://flink.apache.org/ for details.

Parent is one side of the "why not". The other is, "why *would* we use ssh for everything?".

The summary (I'm not going to bother reading the article) makes it sound like they want to use ssh in place of HTTPS. That's stupid. We have secure protocols for many things that each fit correctly (ipsec, https, sftp, ssh, various-vpns (ssl/tls/etc), s/mime, pgp/gpg, etc).

The summary says, "SSH does have several cool features over HTTP/2 though, like built-in client authentication which removes the need for registration and remembering extra passwords."
WTF? I'm guessing they're referring to public key authentication, which HTTPS has (and I'd assume would work in HTTP/2 as well). You can use client based ssl certs for auth. It's a PITA, just as it would be to use ssh keys - the client side management of said info would need to be solved in a very dumbed down and friendly way.

Some other things it has (and I assume they imply that HTTPS does not have?):

* Binary protocol. ssh just sets up a secure channel. It's not a binary protocol for all the other bits (like shell commands), which are all encrypted plain text. Ditto to HTTPS/SSL/TLS... where's the difference here? HTTP/2 proposal would have a binary protocol, though I don't really see much benefit to that.

* mandatory encryption. ssh = nope. You can, but you could also allow the null cipher. IE. it has to be configured for that way of operations. HTTPS/SSL/TLS - enable HSTS header and do a permenant redirect on port 80 to 443, done.

* key pinning. Oh, you mean like this: https://www.owasp.org/index.ph...

* multiplexing. I'll admit this may be a benefit, but I see little benefit over simply using multiple connections with keepalive. Prove there's an actual performance benefit and then we'll talk. Meanwhile, as parent mentioned, ssh connection establishment is VERY SLOW in comparison to HTTPS.

* compression. You mean like this, "SSLCompression On". http://httpd.apache.org/docs/c...

Please note, I'm not saying HTTP/2 is bad, nor that the features in HTTP/2 fall to the same points above. I'm saying those points do not apply, apply poorly, or already have a better solution in HTTPS as compared to SSH.

*nudge* *nudge* http://incubator.apache.org/wa... *wink* *wink*

I have seem at least 10 benchmarks showing the same. Do your own research and try to be a little less biased. Latest apache does the same as nginx now. Event driven model with multiple connections handled by a single thread. That is as simple as that and it shouldn't be too hard to understand that using the same techniques, apache will indeed be as fast.

See a more detailed benchmark here: (search for nginx for comparison)
https://people.apache.org/~jim...

It's worth having a look at server name indication which is supported by modern browsers. This allows multiple secure vhosts and certs per IP address.

I used to be a big fan of Hadoop until I gave Apache Spark a try. My god, the speed, ease of use and install simplicity was just ridiculous. I mean, words failed me the first time I used it, I got it installed and working under 2 hours and it was so blazing fast, it was just a joke.

For people who took a look a few years back, it has matured a lot from an interesting prototype to something I now use in production on my clients data. Documentation is still a bit sketchy for niche functions but it's improved a lot also.

https://spark.apache.org/

I know this is off topic but...

> When RH (which is, both in business model and revenue, a small player in the IT panorama)

I continue to hear this and see absolutely no evidence of it. I see evidence to the contrary, in the US, India and Europe, over the last 20 years.
Generally, it's RPM/RH that is first listed. It's not alphabetical. This isn't because they are lucky. The simple explanation is that RH is the most frequently used and therefore put at the top as a simple matter of UI layout (most common choices go to the top of a list, within reason).

Let's just pull some random packages out of the web -

RH nearest top:
http://www.aerospike.com/downl...
http://dev.nuodb.com/download-...
http://wiki.nginx.org/Install
http://cassandra.apache.org/do... (rpm mentioned before deb)

Debian nearest top:
http://dev.mysql.com/downloads...

This is a fun game, pick me a list that shows more Debian love!
I would like to keep a pulse on things but I just don't see this assertion (that RH is the marginal market) bearing out as anything but wishful thinking.

If you want your Hadoop cluster to be fast and easy to use, go with Spark https://spark.apache.org/.

"many eyes make all bugs shallow" is logically correct. No it is not. Bugs are usually found after they manifest themselves. Then the bug is searched for. Before that, it happens extremely rarely that a bug gets found in the source code.

It is a statistically higher probability that a bug *has the potential* to be identified quicker and/or fixed quicker with FOSS than with closed source. If that would be the case, we would hear regularly about such bug fixes :D

Btw, "professionals"? Are you serious? You seriously think that FOSS developers are inferior in their competency compared to a developer who works at a company? I mentioned "hobbyists" did, I not? Of course there are plenty of professional developers in the FOSS area. But there are also plenty of very bad developers.

E.g. look at the source code of lucene: http://lucene.apache.org/ half of it is completely unmaintainable.

Before opening your mouth so wide you should perhaps stop simply "using" FOSS but look into the sourcecode or debug it.

I saw plenty of "bad code" form professionals ... however I saw no real prime example of good code in FOSS.

The reason why many OSS is _good_ and has relatively low bugs is because a small core team of _professionals_ is crafting it. Not because it is FOSS or because many eyes are looking on it.

If the process a) is a bash script itself

If you're using fastcgi with a wrapper script (the recommended configuration for mod_fcgid+PHP), it's time to check the wrapper script. It should not need to be a bash script.

FCGIWrapper /usr/lib/cgi-bin/php5-wrapper .php

I would have thought the Great Java Wars had taught everyone that true cross-platform development is a chimera that isn't worth either the vendor or developer's effort. Platform vendors compete on features -- cross platform is antithetical to competition on features.

Remember when people called browsers "platforms" and the websites were "applications"? 20+ years of the web has shown that cross platform works, that what counts as a platform is malleable, and that the features companies compete over, change over time. Today in mobile language is a feature in contention, but if Cordova (et al.) become popular, Apple and Google will compete over different features.

While CloudStack is under an opensource license, Citrix is gaming the system to appear open while keeping a leach on what functionality goes into the mainstream form of this "open" project.

David Nalley brings up that the benefits of CloudStack being an Apache project is that it provides transparency and makes sure that no one company dominates the project. Both of these claims are misleading.

In reality, there is not the type of transparency you would like to have for something claiming to not allow any one company to dominate the project. The list of Project Management Committee members does not indicate who any of them work for. A quick Google of the names on the list seems to indicate that Citrix has more members on the PMC than any other company. While they may not hold over 50%, it is unclear how many others of the PMC have indirect allegiances with Citrix. Also, given that any one member of the PMC can respond to patches with effectively veto power, it should be clear how even holding a small percentage of the PMC can still have a chilling effect on what makes it into the project. There is a very high learning curve to understanding the CloudStack source code enough to contribute and it doesn't take much to discourage someone from trying to contribute.

While this may seem like unwarranted fear, you should keep in mind that Citrix has already crippled the Open Source community's efforts regarding XenServer. In response to Xen being nothing more than a hypervisor and XenServer becoming the prefer API by with to managed it, a GPL/LGPL project was started called XCP (Xen Cloud Platform). This went as far as to include features which Citrix considered top tier feature which should only available for big bucks paided to Citrix. For example, XCP had a "Site Recovery" feature which XenServer Advanced and XenServer Enterprise does not provide. Instead, Citrix expected customers to pay for XenServer Platinum to get such features.

To deal with the XCP threat to their income model, Citrix released XenServer "Free" Edition and put pressure to put a stop to further development of XCP. Since XenServer Free is under a Citrix EULA which explains that "'XenServer Technology' means proprietary object code of the XenServer product that is not Open Source Code [...]" then Citrix can make sure that XenServer Free always remains crippled in comparison to the open source XCP project they ended and in comparison to their own paid versions. While Citrix employees would prefer to call XCP "deprecated," the truth is that they killed it.

As such, Apache CloudStack's support of XCP remains crippled and buggy--after all, if XCP is deprecated then anyone from the PMC should be able to rubber stamp any effort to improve support as also deprecated/wasted effort. But the fencing of CloudStack functionality does not stop there. Like "XenServer Technology" that they want closed up under a tightly controlled EULA, they have other paid products to extend CloudStack to compete with basic functionality of OpenStack. For example, efficient orchestration will never be part of the Apache CloudStack project because then there would be no reason for anyone to buy Citrix CloudPlatform. OpenStack Horizon module provide a portal for customers to self-service their use of a public cloud and is part of the base of OpenStack. Won't be part of the functionality of CloudStack because then there will be no reason for anyone to buy Citrix CloudPortal.

To put icing on the cake, even if you accept that critical functionality will be artificially kept out of the mainstream CloudStack project and choose to pay for support from Citrix, they continue to treat Linux as a second-class citizen. For help with dealing with the some of the issues with deploying CloudStack (critical errors like "java.lang.NullPointerException"), Citrix demanded to access an on-premises workstation via GoTo Meeting

Nope... A vulnerability in a library is not a vulnerability in the underlying programming language. Just because the JRE *is* an execution environment, does not mean that the execution environment being run by a malicious user is a vulnerability in the JRE. That's like saying, there's a vulnerability in C, because Flash is written in C and there's a Flash vulnerability. The point is there is a **critical** vulnerability in older versions of the Struts library, which is used to escalate privileges to the JRE. Once you have rights to the JRE, you can copy files and have the JRE execute system commands using the rights given to it by the OS which should not be a root user(honestly, if they wrote the payload in Java this step would not be needed, a server environment is entirely capable of performing DDoS attacks). Also, I'm calling BS on this exploiting a known Tomcat vulnerability. There are no known "critical" vulnerabilities in any version of Tomcat :
http://tomcat.apache.org/secur...
http://tomcat.apache.org/secur...
http://tomcat.apache.org/secur... ...
Basically, people need to patch Struts 2 because of this fucker:
http://struts.apache.org/relea...
which was fixed in July 2013:
http://struts.apache.org/downl...

Nope... A vulnerability in a library is not a vulnerability in the underlying programming language. Just because the JRE *is* an execution environment, does not mean that the execution environment being run by a malicious user is a vulnerability in the JRE. That's like saying, there's a vulnerability in C, because Flash is written in C and there's a Flash vulnerability. The point is there is a **critical** vulnerability in older versions of the Struts library, which is used to escalate privileges to the JRE. Once you have rights to the JRE, you can copy files and have the JRE execute system commands using the rights given to it by the OS which should not be a root user(honestly, if they wrote the payload in Java this step would not be needed, a server environment is entirely capable of performing DDoS attacks). Also, I'm calling BS on this exploiting a known Tomcat vulnerability. There are no known "critical" vulnerabilities in any version of Tomcat :
http://tomcat.apache.org/secur...
http://tomcat.apache.org/secur...
http://tomcat.apache.org/secur... ...
Basically, people need to patch Struts 2 because of this fucker:
http://struts.apache.org/relea...
which was fixed in July 2013:
http://struts.apache.org/downl...

Nope... A vulnerability in a library is not a vulnerability in the underlying programming language. Just because the JRE *is* an execution environment, does not mean that the execution environment being run by a malicious user is a vulnerability in the JRE. That's like saying, there's a vulnerability in C, because Flash is written in C and there's a Flash vulnerability. The point is there is a **critical** vulnerability in older versions of the Struts library, which is used to escalate privileges to the JRE. Once you have rights to the JRE, you can copy files and have the JRE execute system commands using the rights given to it by the OS which should not be a root user(honestly, if they wrote the payload in Java this step would not be needed, a server environment is entirely capable of performing DDoS attacks). Also, I'm calling BS on this exploiting a known Tomcat vulnerability. There are no known "critical" vulnerabilities in any version of Tomcat :
http://tomcat.apache.org/secur...
http://tomcat.apache.org/secur...
http://tomcat.apache.org/secur... ...
Basically, people need to patch Struts 2 because of this fucker:
http://struts.apache.org/relea...
which was fixed in July 2013:
http://struts.apache.org/downl...

Nope... A vulnerability in a library is not a vulnerability in the underlying programming language. Just because the JRE *is* an execution environment, does not mean that the execution environment being run by a malicious user is a vulnerability in the JRE. That's like saying, there's a vulnerability in C, because Flash is written in C and there's a Flash vulnerability. The point is there is a **critical** vulnerability in older versions of the Struts library, which is used to escalate privileges to the JRE. Once you have rights to the JRE, you can copy files and have the JRE execute system commands using the rights given to it by the OS which should not be a root user(honestly, if they wrote the payload in Java this step would not be needed, a server environment is entirely capable of performing DDoS attacks). Also, I'm calling BS on this exploiting a known Tomcat vulnerability. There are no known "critical" vulnerabilities in any version of Tomcat :
http://tomcat.apache.org/secur...
http://tomcat.apache.org/secur...
http://tomcat.apache.org/secur... ...
Basically, people need to patch Struts 2 because of this fucker:
http://struts.apache.org/relea...
which was fixed in July 2013:
http://struts.apache.org/downl...

Nope... A vulnerability in a library is not a vulnerability in the underlying programming language. Just because the JRE *is* an execution environment, does not mean that the execution environment being run by a malicious user is a vulnerability in the JRE. That's like saying, there's a vulnerability in C, because Flash is written in C and there's a Flash vulnerability. The point is there is a **critical** vulnerability in older versions of the Struts library, which is used to escalate privileges to the JRE. Once you have rights to the JRE, you can copy files and have the JRE execute system commands using the rights given to it by the OS which should not be a root user(honestly, if they wrote the payload in Java this step would not be needed, a server environment is entirely capable of performing DDoS attacks). Also, I'm calling BS on this exploiting a known Tomcat vulnerability. There are no known "critical" vulnerabilities in any version of Tomcat :
http://tomcat.apache.org/secur...
http://tomcat.apache.org/secur...
http://tomcat.apache.org/secur... ...
Basically, people need to patch Struts 2 because of this fucker:
http://struts.apache.org/relea...
which was fixed in July 2013:
http://struts.apache.org/downl...

Not sure how current it is, but when I was looking for the same a few years back all that was really available for PHP was HTML->PDF libraries which were not sufficient for anything but the most basic forms. A decent invoice form was hard to get right with these tools. Then I came across FOP. Or more specifically XML-FOP. Combine that with a little XSL and the output was amazing, and could do more than the HTML converters. The only problem is that the FOP tool was a Java based program so PHP would need to execute a shell command to call it. With tight control of what info was passed to that shell command, it seemed an appropriate trade-off for the job at hand. You can still get FOP in the ubuntu repos - apt-get install fop. The learning curve for FOP is a little steep to begin, but no more than any other XML dialect. And being XML, you have a lot of options in building the required FOP file. I opted to put my data into my own XML file, then utilize an XSL file to convert it if/when needed. More details here: http://xmlgraphics.apache.org/...

Might be worth checking out Apache's OpenMeetings. That comes with the advantage of being a run-your-own-server solution.

I don't know about that. Scala is getting more and more popular in "Big Data", and it doesn't get more hip than that?

Apache Spark which seems destined to replace Hadoop is written in Scala:
https://spark.apache.org/

TCL is both awesome and mature. It is also evolving, but the maintainers are very careful to maintain backwards-compatibility (unlike the Ruby-crowd). Two different Apache-modules exist.

Unlike with PHP, you can also write long-living TCL-programs — though PHP core is Ok, various extensions leak memory because nobody really uses the language for anything other than short-lived web-pages. Adding a GUI to your non-web program is also easy (with Tk), as is handling the cases, where GUI is not available — you can degrade gracefully to a non-GUI mode, rather than see the program refuse to even start.

The only real competitor to Tcl is Python, which is what Google are using, but extending Tcl with your C/C++ code is much easier, than extending Python (or any other candidate — Tcl's API is the best thought-out and stable).

> Unfortunately, I've never hear a seemingly viable proposal for how to solve the problem.

Artificial intelligence. I'm not joking, this is a job that is ripe for a computer to do the filtering for you.

Today we have blunt intstruments like adblock, ghostery, noscript and requestpolicy. But we also have pseudo-intelligent agents like spam-assassin and NoMoRobo. The inevitable result is an arms-race of ever more sophisticated ad-filtering and more sophisticated evasion methods. But at some point the methods of evasion overwhelm the message of the ad in the first place (who hasn't received one of those uber cryptic emails that, if you even bother, take you 10 minutes to figure out what they are even trying to sell you? It was cryptic enough to get past the spam filter but it had to be useless to do so.) I'd like to see a future where we all have an "ai personal assistant" who filters everything for us. You could wear the equivalent of google-glass but instead of showing you ads, it would overlay billboards and signs with lolcats.

Netflix has its own caching.
Amazon has their own caching.
Akamai has their own caching.
Limewire has their own caching.

Apache has their own caching http://www.apache.org/dyn/closer.cgi/ (talking about download their software, not their cache server).
Sourceforge has their own caching http://sourceforge.net/apps/trac/sourceforge/wiki/Mirrors/.

(I think you can add alot more of my examples).

Why have gazillions of differents caching solutions when you only need one, which honor Net Neutrality by design?

Well, since there's now directory servers that support triggers, stored procedures, and views, nothing is sacred!