161–170 of 184 posts
You want to program stuffs in the browser ? use javascript and html5 apis.
You want to do socket stuffs in the browser? use a proxy server.
But dont expose your users to exploits by making them install Java.
You want to build future proof solutions ? stop using applets because you cant learn javascript.
Earlier quoted context omitted.
This is HN, mind your language please.
It's a copy of one of the comments on the link. It should have been in quotes at a minimum.
Somehow, as a thank you, he decided to insult us.
sigh
Earlier quoted context omitted.
Java actually installs malware (the Ask toolbar) unless you are careful enough to deselect it during the installation/update process.
Uh no. That is not "malware". Unwanted software yes but not malware.
Most common search suggestions for Cydoor (well known adware): http://i.imgur.com/iXqJdzU.png
Most common search suggestions for Ask Toolbar: http://i.imgur.com/HziYjkZ.png
Looks pretty similar to me.
Earlier quoted context omitted.
I just want to confirm 'gfritzsche' in you being wrong, and ranting about a lot of stuff that is just wrong . You should delete your comment.
I went through this routine yesterday. Updated Java and restarted Firefox. I can 100% vouch for seeing a warning about Java being outdated. The warning was still there. I stand by it and I wont delete or edit my comment. As a dedicated Firefox-user who dislikes the direction Chrome is taking, I still say Firefox has a problem here. This is something real users are experiencing. I believe this as a whole will have a v…
http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-f...
Earlier quoted context omitted.
> You can still easily run Java applets in Firefox 24 and beyond, you just need to click the red lego block in the upper left corner and allow it. [1] Allow me to disagree and to tell you what happened last weekend: Last Sunday I had a call from my stepfather who "couldn't run the website to order agro food" anymore. This website runs a Java applet to manage agro food orders on-line and the code isn't signed (it's a…
I can't edit my message anymore so I reply here. After reviewing the facts by discussing them with nknighthb it appears the warning message that prompted me to blame Mozilla for a confusing warning message was due to Oracle and their Java warning pop-up. https://dl.dropboxusercontent.com/u/202857/java.png My apologies :], I am a little bit ashamed for not spotting it sooner.
This is honestly what makes the Firefox warnings even more damaging than they already are.
If a brave user decides to click past the "DO NOT ENTER" sign on the Firefox warning, they are immediately presented with another worrying warning, popped up by the Java plugin. What kind of fool says "yes, please go ahead and do this dangerous thing" when two separate pieces of software have already told them not to? Not most, unfortunately.
At least I can make the Java plugin warning dialog be relatively calm by signing my JARs. The Firefox one is completely beyond my control.
I'd like to know if the Firefox developers have details on exploits that bypass the Java plugin dialogs. If they do, I'd like to know as well. If they don't, that means they're duplicating a security feature that's already in the plugin... what's the good of that? It just confuses and frightens the users of valid, secure Java applets.
This will be more great publicity for Norwegian government-owned consultancy Evry, which has built the BankID Java Applet which is used for authentication of each and every online consumer money transaction performed in the country. However, it is about time - I've heard online banking developers talk crap both about BankID and the underlying online banking infrastructure in the country, and security holes due to Jav…
Earlier quoted context omitted.
That's a fair question. However, I don't think some people posting in this discussion would like the equally fair answer. Logically, if Firefox is not going to support long term stability and compatibility -- and clearly it doesn't in the case we're discussing -- then the only possible conclusion is that Firefox can't be part of an effectively managed IT infrastructure for these kinds of organisations. That means the…
Yes, Mozilla has been pretty clear on this. If you want more stability, you need the ESR release, and if that's not enough, you're out of luck. Mainline Firefox is simply not intended for use within organizations that demand the kind of stability you want. You need to evaluate the ESR release, and/or find a different browser entirely. IE may indeed be the best option if you only support Windows clients. Though Micros…
I'm not sure who mainline Firefox is intended for any more. That's part of the problem, I think.
It seems like Mozilla are chasing Google to the exclusion of almost anything else, and the main goal for both of them seems to be ticking boxes to say they have more bleeding edge features, even though hardly any real projects can actually use most of those features because they aren't stable and portable enough yet. Meanwhile, users get interfaces that subtly shift around every few days, developers are fighting a constant battle just to stand still, and as we've been discussing, organisations can't manage large-scale deployments robustly at all any more.
Earlier quoted context omitted.
Adapt or die. An unfortunate comment, because some of the devices I had in mind when writing those last few posts are in fact medical equipment. If Java-based UIs are no longer readily available to clinical staff the way they were last week, then effectively their instruments just got broken. Delays and increased suffering for patients are all but certain consequences until the IT staff have chance to fix things agai…
> If Java-based UIs are no longer readily available to clinical staff the way they were last week, then effectively their instruments just got broken. Would that be a failure of Firefox (or other browser vendors) or a failure of hospital IT staff to manage the medical devices / desktops / network effectively?
I work with the NHS in the UK; quite a few of the medical professionals are forced to use IE6 or IE7 because the hospital IT staff are managing their medical devices / desktops / network effectively, just as you say.
When Firefox makes a decision like this, what they apparently did not seem to consider is that they are drawing a cutoff line which has serious costs to some of their users. I didn't see any discussion of this whatsoever in the issue thread.
Imagine a relatively forward-thinking hospital that has been able to allow their staff to use fairly-recent versions of Firefox (once new versions have been vetted by IT). Changes like this may force them to stop deploying new versions completely, until some time possibly a decade from now when they're finally able to replace the Java-based UI.
Earlier quoted context omitted.
Adapt or die. An unfortunate comment, because some of the devices I had in mind when writing those last few posts are in fact medical equipment. If Java-based UIs are no longer readily available to clinical staff the way they were last week, then effectively their instruments just got broken. Delays and increased suffering for patients are all but certain consequences until the IT staff have chance to fix things agai…
> Delays and increased suffering for patients are all but certain consequences If the product you are building is not future proof it is your problem not Mozilla's. Dont blame Mozilla for your poor technology choices. Applets will eventually stop working, and you'll be responsible if your product fails , not Mozilla. Dont blame anybody else but you. You broke the medical staff instruments by choosing or maintaining a…
Nothing is future-proof if the people controlling the platforms move the goalposts. We have standards and value backward compatibility for a reason: it's because violating those standards and breaking that compatibility hurts. And it's going to become Mozilla's problem if they continue down this path, because Firefox will cease to be a viable browser choice for a significant proportion of their potential market.
Dont blame Mozilla for your poor technology choices. Applets will eventually stop working
I don't know why you're writing as if I personally broke these medical devices. I've never personally worked on any of those projects, I'm just familiar with them and citing them as examples of why this sort of change is damaging.
In any case, people really should get off the "Java applets is a dead technology" bandwagon. Viable replacements using HTML/CSS/JS are very recent developments, and people have been developing web-based user interfaces for all kinds of devices for decades. Of course they're not all going to throw out all that work and rewrite everything from scratch. There's nothing wrong with it, and contrary to your claim, there is no reason those applets must eventually stop working. They'll work just fine as long as browsers run Java applets, which they've been doing just fine for many years.
Obviously applets will stop working if browser makers deliberately drop support for them even though it's been available for a very long time. However, that's like saying obviously CSS3 is no use for anything because it's not all W3C standardised in stone yet so you're stupid if you use it today because it might all be different at some arbitrary point in the future that no-one can predict. You can shoot down any technology, no matter how modern and trendy, with such a generic argument, but it doesn't demonstrate anything particularly helpful to do so.
You broke the medical staff instruments by choosing or maintaining a dead technology thus putting patient lives in danger.
No, I didn't, but if the serious software I work on were medical in nature, you could literally bet your life that I wouldn't be letting either Java or Firefox anywhere near it and would be using an entirely different level of engineering practice to build it, as I do for certain projects in other fields where reliability is essential.
However, while we build the literally life-or-death systems that way, chances are the word processor, KVM, and, yes, web browser that organisations doing vital work use for day-to-day activities are not developed to the same standards. Breaking them still hurts, if only in efficiency (which can obviously still be harmful in a medical context). Unless you're claiming that all software that runs in any medical facility must be developed to the same standards as control software for high-risk, safety-critical systems, again, your argument is so generic that it doesn't really prove anything interesting.
