LWN: Comments on "Monomania (Tux Deluxe)"

Monomania (Tux Deluxe)

malor — Sun, 25 Oct 2009 08:17:26 +0000

Crap, I should have included this quote in the post above:

It's not like the patents at issue (which never seem to be properly defined)

My reply isn't to the main point of your post, but rather to the 'never properly defined' comment. There's a reason why the handwringing is mostly noise and not much signal... it's deliberate, to protect everyone involved.

Monomania (Tux Deluxe)

malor — Sun, 25 Oct 2009 08:10:16 +0000

It's important to understand that there's a reason for not specifically pointing out the patents: knowing infringement of a patent exposes you to treble damages in a court case.

If you tell a developer, "Mono violates Microsoft patents, and you could be sued", that's just a warning. If you say, "Mono violates Microsoft patent #foo when it uses this particular trick to compile code at runtime", you have now put them in a tight spot; they have to remove the offending code immediately or be three times as exposed if the issue ever goes to court. The person doing the research becomes 'polluted', and anyone he or she communicates that research to is polluted as well. It can be argued (and probably would be) that if anyone on a software project team knew about the patents, then the entire project is liable for treble damages. So you've instantly forced the project to either remove code, or drop poisoned developers.

That's why you see it always painted obscurely, instead of as specific documentation, because if they document it, and you read it, you're screwed. Since they're trying to help you, not hurt you, they stay as obscure as they can. It's FUD, but it's FUD for your benefit, not to confuse you into making bad decisions.

No need

nim-nim — Fri, 23 Oct 2009 06:16:52 +0000

> I am not talking about random people commenting on random font rendering
> samples in a blog post. I don't care what they say. I am talking about
> delivering working products to paying customers... :-)

Typophile is not random people it's the web lair of professional font creators that need too deliver working fonts to paying customers

> No one is arguing with that. However you seem to assume that
> typographically correct rendering is always required or even preferable
> on a computer screen. When that screen is low DPI and low color,
> crispiness is all that matters.

And I contend that's a user preference, as proved by all the OMG how can I remove ugly crispy bitmap fonts post that happen every time bitmap fonts are accidentaly activated for a large user base

> I want and need both a)

BTW people seem to assume no-AA is "better", in large part because it's supposed to be faster. With modern font libs and GFX drivers, since everyone optimizes the general case users want (AA), AA rendering will be faster.

Also if you push your customers in small text at low-dpi land you'll just make non-i18n apps. Latin scripts are relatively resistant to low-dpi situations, compared to asian ones (because an ideogram for example needs higher detail density than a latin letter)

No need

nim-nim — Fri, 23 Oct 2009 06:04:39 +0000

To the contrary it shows that the Linux font rendering is not as bad as people pretend, and that using the patented hinting process as windows does would be no silver bullet. It also points to ways to make freetype even better (according to the author).

Anyway the freetype devs are definitely aware of this article, if it's not implemented yet that's either because there is some legal problem, or xorg is missing the infra (typically xorg is terrible at color correction so gamma tricks are un-implementable on its current state), there is some other point missed in the article (for example, it would make desktop rendering unbearably slow with current drivers), or people just do not have the time to finish it up (I don't remember which case it is).

But anyway if you're interested in it I'm sure they would welcome patches.

And (to repeat myself) rasterization is only a very small part of font processing.

No need

mikov — Fri, 23 Oct 2009 01:13:51 +0000

Sorry for replying to myself, but I think this article is a worthwhile complement to my point:
http://antigrain.com/research/font_rasterization/

It show how the current state of Linux font rendering is not particularly good, and how it can be improved. Has anything been done in that direction?

No need

mikov — Fri, 23 Oct 2009 00:48:59 +0000

> Do you really want to argue there is nothing wrong with java font
> processing when it can not even parse the default format of most new
> font projects? Even giant multi-year efforts such as
> http://www.stixfonts.org/[1]

No. As I said, I believe you when you you say that there are problems. I thought we agreed that it is a moot point because it _has_ to be replaced anyway.

I am pointing out that the move to Freetype, while necessary and unavoidable, and while improving some things (as you are saying), worsens others.

I see a kind of complacency with the state of Linux font rendering, while it has clear shortcomings in some aspects.

> Be consistent: either font processing is required, and Java is not on
> the level expected today, or it isn't, and comparisons of font rendering
> are irrelevant

I am consistent. For my purposes (mostly embedded development) the current state of closed source Java font rendering works better than Freetype. Additionally, since I believe that Java has no future on the desktop, the problems you are describing are not that critical.

> And many people commented on the links I posted that the Windows font
> rendering you think is obviously better is not acceptable either. So
> don't pretend it's an objective statement.

I am not talking about random people commenting on random font rendering samples in a blog post. I don't care what they say. I am talking about delivering working products to paying customers... :-)

Windows font rendering is objectively and undeniably better at low resolutions without anti-aliasing. To deny that fact out of misguided open source loyalty is to prevent improvement in that same open source.

> That windows achieves "crispness" at the cost of distortion its not
> subjective it's a fact that can easily be checked (and has been by many
> people). What's subjective is the right balance between "crispness" and
> "no distortion". It's a compromise ie there is no 100% good solution.

No one is arguing with that. However you seem to assume that typographically correct rendering is always required or even preferable on a computer screen. When that screen is low DPI and low color, crispiness is all that matters.

Secondly, while there is no 100% good solution, it is enough to try reading this very page without anti-aliasing on Windows and Linux, to become convinced which solution is at least better. And I am saying this after having worked exclusively with a Linux desktop for many years - so my brain has been trained to like the Linux kind of rendering. Believe me, I eally want to like Linux better :-) But for now the path for that is to really make it better, rather than convince myself that wrong is right...

> It should be but it is not. Even MS continues to invest heavily in font
> processing tech. So obviously they disagree with you on the "solved"
> part.
>
> The only solution everyone agree would work would be to increase pixel
> density just like happened video-side for hd video.

I hear you... I am typing this on a huge monitor with huge fonts and I have to say the fonts in Linux look lovely...

> The AA settings let you choose a point between the two curbs on
> http://damieng.com/blog/2007/06/13/font-rendering-philoso...
>
> Of course it will cause reflow. That's obvious math. If you don't want
> reflow do not allow changing the settings (your font processing won't be
> any better quite the contrary but you'll have hidden an un-obvious, for
> laymen, side-effect of grid-fitting)

You are missing my point, perhaps because we are talking about two separate issues. These are conflicting goals:
a) Crisp rendering without anti-aliasing at small sizes. It is by definition typographically incorrect, but more readable.
b) Accurate sub-pixel rendering, even at the expense of readability (typically at smaller sizes). Since it is accurate, it will not affect reflow. For example, Adobe Acrobat works this way.

I want and need both a) and b), with a way to control when I get which. The problem is in Linux out of the box I get neither! I get both ugly fonts without anti-aliasing, and I get inconsistent reflow with anti-aliasing.

No need

nim-nim — Thu, 22 Oct 2009 20:28:56 +0000

> That is unimportant. As I said, Java is not suitable for the desktop, so
> any desktop-related problems are non essential.

Do you really want to argue there is nothing wrong with java font processing when it can not even parse the default format of most new font projects? Even giant multi-year efforts such as
http://www.stixfonts.org/

Be consistent: either font processing is required, and Java is not on the level expected today, or it isn't, and comparisons of font rendering are irrelevant

> I am sorry, but that is rubbish. I am talking of a specific engineering
> problem - rendering text on a small embedded B&W LCD display. The output
> generated by the Linux standard libraries when using True Type fonts is
> not acceptable. There is nothing subjective there.

And many people commented on the links I posted that the Windows font rendering you think is obviously better is not acceptable either. So don't pretend it's an objective statement.

> It makes no sense to press on here. Since according to you anything is
> by definition subjective then there is nothing to discuss.

That windows achieves "crispness" at the cost of distortion its not subjective it's a fact that can easily be checked (and has been by many people). What's subjective is the right balance between "crispness" and "no distortion". It's a compromise ie there is no 100% good solution.

> I am not talking about high quality typography here. Displaying text on
> a small two-color display should be a solved problem.

It should be but it is not. Even MS continues to invest heavily in font processing tech. So obviously they disagree with you on the "solved" part.

The only solution everyone agree would work would be to increase pixel density just like happened video-side for hd video.

> I am not convinced that it is acceptable to perform reflow as a result
> of anti-aliasing.

The AA settings let you choose a point between the two curbs on
http://damieng.com/blog/2007/06/13/font-rendering-philoso...

Of course it will cause reflow. That's obvious math. If you don't want reflow do not allow changing the settings (your font processing won't be any better quite the contrary but you'll have hidden an un-obvious, for laymen, side-effect of grid-fitting)

No need

mikov — Thu, 22 Oct 2009 19:48:53 +0000

> Part of the non-native feel is non-native font rendering. Also try to
> explain to users why an .otf fonts that works perfectly well in other
> apps is rejected by the java app. At last count there were ~ 400 TTF
> (plain TrueType or OpenType TT) files and ~ 100 OTF (OpenType CFF) files
> in Fedora, with OpenType TT growing fast (TrueType is years older than
> OpenType CFF, so it had a lot more time to create a big font pool)

That is unimportant. As I said, Java is not suitable for the desktop, so any desktop-related problems are non essential. Also, I contend that the "non-native feel" of font rendering is one of the smallest problems for desktop Java. For one, Java's rendering looks very similar to Windows to my eyes, and that is where the desktop is. If everything else was fine, this would not prevent Java desktop usage.

> This is exactly the kind of test which people think is objective and is
> proved subjective time and time again

I am sorry, but that is rubbish. I am talking of a specific engineering problem - rendering text on a small embedded B&W LCD display. The output generated by the Linux standard libraries when using True Type fonts is not acceptable. There is nothing subjective there.

>> Now go to Windows 2000
>> with disabled anti-aliasing and compare. These are facts.
>
> The fact is that they are different. Which one is better is 100%
> subjective. Windows achieves some bitmappy effect at the cost of
> distorting the glyphs shapes more, and people will like it or not
> depending if they attach more importance to the first or the second
> part.

It makes no sense to press on here. Since according to you anything is by definition subjective then there is nothing to discuss. Further, if you insist on believing that non-hinted+non-antialiased _screen_ rendering in Linux is in any way superior to non-antialised _screen_ rendering in Windows (emphasis on screen, not high-DPI printer!), then there is no common ground.

However, if you try to deliver a product using that supposedly superior rendering (non-hinted, non-antialiased, small fonts), I don't expect many people would like it.

I am not talking about high quality typography here. Displaying text on a small two-color display should be a solved problem.

> You're not a font expert. The pixel density of a typical computer screen
> is not sufficient to render a vector font accurately, so the rendering
> algorithm needs to perform rounding on pixel lines (it is worse for CJK
> glyphs than for Latin, CJK computer screen rendering is horrible no
> matter what rendering tech you use, the pixel density is just too low.
> People have forgotten but before 300dpi+ laser printers it was the same
> mess print-side, and today's computer screens usually target ~ 100 dpi).
>
> If you do too much rounding the glyphs lose their shape. If you don't do
> enough they are blurry. The AA settings let the user choose the
> compromise they prefer. If the computer never tried to round you'd never
> see the reflow you complain of. Ironically this rounding process is why
> you like Windows rendering so much (Microsoft uses it more heavily than
> Linux, and Apple less).

Yes, I am familiar with the big hoopla about Apple's fonts being more blurry and the associated discussions.

I am not convinced that it is acceptable to perform reflow as a result of anti-aliasing. I am pretty sure Adobe Acrobat doesn't do that. IIRC, Apple wouldn't do that either since they are simply rendering precisely and letting anti-aliasing take care of the rest (thus the blurriness).

Also, I should note that this is not about me liking Windows rendering. It is about calling a spade a spade. Microsoft has probably invested tens of man-years into this, so it is no surprise that they would produce better results. (And licensing the patents doesn't hurt either).

I also agree that on high-DPI displays with anti-aliasing this is not an issue.

No need

nim-nim — Thu, 22 Oct 2009 18:54:16 +0000

> non-native widgets

Part of the non-native feel is non-native font rendering. Also try to explain to users why an .otf fonts that works perfectly well in other apps is rejected by the java app. At last count there were ~ 400 TTF (plain TrueType or OpenType TT) files and ~ 100 OTF (OpenType CFF) files in Fedora, with OpenType TT growing fast (TrueType is years older than OpenType CFF, so it had a lot more time to create a big font pool)

> Speaking about Linux font rendering: in the case I described the
> qualification "absolutely horrible" is not subjective. It is a fact. Try
> rendering a small font on a black&white embedded LCD display. Or you can
> simply try disabling all anti-aliasing on your Linux desktop - you will
> also see something which is also objectively bad.

This is exactly the kind of test which people think is objective and is proved subjective time and time again

> Now go to Windows 2000
> with disabled anti-aliasing and compare. These are facts.

The fact is that they are different. Which one is better is 100% subjective. Windows achieves some bitmappy effect at the cost of distorting the glyphs shapes more, and people will like it or not depending if they attach more importance to the first or the second part.

> Or try another experiment that always amazes me: change the
> anti-aliasing settings and observe the text in your browser being
> re-formatted :-) WTF? I am no font expert, but shouldn't the same text
> occupy the same space visually regardless of anti-aliasing settings?

You're not a font expert. The pixel density of a typical computer screen is not sufficient to render a vector font accurately, so the rendering algorithm needs to perform rounding on pixel lines (it is worse for CJK glyphs than for Latin, CJK computer screen rendering is horrible no matter what rendering tech you use, the pixel density is just too low. People have forgotten but before 300dpi+ laser printers it was the same mess print-side, and today's computer screens usually target ~ 100 dpi).

If you do too much rounding the glyphs lose their shape. If you don't do enough they are blurry. The AA settings let the user choose the compromise they prefer. If the computer never tried to round you'd never see the reflow you complain of. Ironically this rounding process is why you like Windows rendering so much (Microsoft uses it more heavily than Linux, and Apple less).

http://people.redhat.com/otaylor/grid-fitting/
http://damieng.com/blog/2007/06/13/font-rendering-philoso...
http://www.codinghorror.com/blog/archives/000884.html
http://typophile.com/node/34393?from=50&comments_per_...

> About the Java font rendering bugs - I am not aware of those, but I
> believe you. Theoretically it would be best if those were simply fixed
> instead of replacing the entire implementation. (I realize that it is
> impossible due to licensing and other crap, etc)

Gratuituously reimplementing stuff that was already available in perfectly fine libs instead of working on new features no one had is another reason Java failed desktop side. Anyway the point is moot, SUN does not own all the code they use for font processing (bought the rights to some piece of crap some years ago and then forgot about it), so they can't open-source it, it will never be part of openjdk, and they'll have to replace it their side too if they don't want to pay engineers to manage two different implementations.

No need

mikov — Thu, 22 Oct 2009 18:27:51 +0000

I am not really complaining about regular desktop usage - my Linux desktop actually looks fine to me; although perhaps some of that is force of habit. I don't deal with visual design, so I am OK as long as it is just acceptable.

But occasionally I notice problems:

- Even though I have the Microsoft fonts, web pages in Firefox look different in Windows (and arguably better, although it is naturally subjective).

- If I disable anti-aliasing completely in the desktop it becomes really horrible. Of course there is no reason to do it, except as an experiment. But it is still depressing. Windows 2000 really looks beautiful and crisp by comparison. As I said, depressing...

- Changing the anti-aliasing settings affects page formatting. I find that very strange.

Back to my initial point, Java's proprietary font rendering exhibits none of these problems, so replacing it with Freetype, while unavoidable, nevertheless could be viewed as a disadvantage in some contexts.

No need

mikov — Thu, 22 Oct 2009 18:16:57 +0000

For sure Java's desktop failure was not caused by its font rendering. Memory consumption, slow app startup, non-native widgets, lack of desktop API integration, and so on, and so on. By virtue of its intrinsic design Java can never work well on the desktop.

Once you realize that Java is not primarily aimed at the desktop, having the same pixel-accurate result everywhere becomes very important again.

Speaking about Linux font rendering: in the case I described the qualification "absolutely horrible" is not subjective. It is a fact. Try rendering a small font on a black&white embedded LCD display. Or you can simply try disabling all anti-aliasing on your Linux desktop - you will also see something which is also objectively bad. Now go to Windows 2000 with disabled anti-aliasing and compare. These are facts.

Or try another experiment that always amazes me: change the anti-aliasing settings and observe the text in your browser being re-formatted :-) WTF? I am no font expert, but shouldn't the same text occupy the same space visually regardless of anti-aliasing settings?

Yes, I know, as Nye commented too, that some of this is probably mostly caused by the patented algorithm and lack of hinting, but it doesn't change the unfortunate end result.

About the Java font rendering bugs - I am not aware of those, but I believe you. Theoretically it would be best if those were simply fixed instead of replacing the entire implementation. (I realize that it is impossible due to licensing and other crap, etc)

No need

nim-nim — Thu, 22 Oct 2009 17:50:11 +0000

Typically, support of new OpenType features and Unicode processing in languages that use non-trivial scripts (ie not English). QT usually lags some behind gtk/cairo.

Rendering is only a very small part of text/font support. Since both GTK and QT use freetype for rendering (but differ higher up in the stack) you won't see rendering differences on the same system (with the same system-wide freetype)

No need

nim-nim — Thu, 22 Oct 2009 17:44:57 +0000

The it must look the same everywhere motto is another big reason SUN desktop efforts failed. No user wants one app to look the same as on some other system he's not using. He wants it to look (and behave) the same as the other apps it uses alongside it (as another example of this judgment error, see the old pre-firefox Netscape themes that were created by marketeers that thought their widgets needed to be synched with the Netscape web site look and feel). Using -insert-other-country-name- conventions in -insert-this-country-name- is not brilliant it's incredibly stupid.

Moreover looks absolutely horrible is a subjective judgement as proved time and time again when someone posts this kind of message on a list (does not matter if it's a pro-AA or anti-AA message) and discovers half the audience disagrees with his obvious statement.

Lastly when I say crap I mean actual font rendering bugs, as in respecting Unicode rules and using OpentType fatures present in the font files.

No need

nye — Thu, 22 Oct 2009 17:28:07 +0000

>For example it looks absolutely horrible without anti-aliasing and small font sizes.

That's not so much the rendering, as the fonts (and the patent issue, in cases where you have well-hinted fonts but are stuck with the autohinter). Open-source fonts are all designed to be heavily anti-aliased, so they aren't well hinted.

I use Microsoft fonts and enable antialiasing for point sizes < 8 and > 14, and I'm very happy with the result as long as I blacklist a handful of fonts that I hate but can't uninstall for silly package dependency reasons.

If you're hoping for better rendering at size 6 with no anti-aliasing, then you'd better have some extraordinarily well-hinted fonts I think, and the patented bytecode interpreter enabled.

No need

mikov — Thu, 22 Oct 2009 16:58:48 +0000

Java font rendering looks fine to me, and anyway the really important thing is that it looks the same everywhere.

Secondly, font rendering in Linux, with what you call "normal libraries" has some pretty serious problems. For example it looks absolutely horrible without anti-aliasing and small font sizes.

I understand why Sun's font rendering has to be replaced, but we can't pretend that the above two problems don't exist.

No need

nye — Thu, 22 Oct 2009 16:47:11 +0000

I can't recall ever noticing any difference in font rendering between GTK and Qt apps, besides perhaps the choice of default font (so not actually a rendering issue). In what way might the fonts in Qt applications be worse?

No need

nim-nim — Thu, 22 Oct 2009 09:01:56 +0000

Java font rendering is crap (probably one of the main reasons it never went anywhere on the desktop). The sooner the openjdk people manage to extirpate all traces of the old SUN font code from openjdk, and switch to normal font libraries (fontconfig, pango, cairo, which *have* proven themselves in major desktop apps like Firefox), the better it will be.

Right now most Linux font bugs read like "it works great in GNOME, so-so in KDE/QT (because it lags pango/cairo in adoption of new font features), it is broken in OO.o (because it inherited from SUN custom text rendering libs, and has not finished migrating to cairo yet), and hopeless in Java"

Re: Only Novell will get sued

jamesh — Mon, 19 Oct 2009 04:57:07 +0000

The point is that changes in that there might be patents that read on code introduced to Java in that time. The existence of Java from before the patent was filed is not a defence if that old version of Java didn't infringe the patent.

And it seems pretty clear that there has been some cross-polenation of ideas between Java and C#/.Net, so the possibility exists. Of course, there it is likely that Sun would examine patents issued to direct competitors like Microsoft to see if they might cause problems.

Re: Only Novell will get sued

cmccabe — Sun, 18 Oct 2009 22:42:28 +0000

Java is much older than .NET. It has now been released as GPLv2 and used as the foundation for a number of open-source projects including Hadoop, Android, Eclipse, etc. It's not a perfect language by any means-- but that's a whole other debate.

I think it's unfair to attack Java as "just as vulnerable as .NET." Any patents that bear on Java are almost certainly held by Oracle, who in general make a lot of money off of Linux and related technologies. They're not going to sue you for using Java because they *want* you to use Java.

On the other hand Microsoft (quite rationally) sees Linux as a threat to their stranglehold on the PC desktop. In general, Microsoft's strategy involves building interlocking pieces of infrastructure. If they can get you to use one or two pieces, they can usually force you to use the rest. Microsoft Visual Studio integrates well with Microsoft SQL Server, which works well with Microsoft .NET, which works well with... etc. Of course, the product at the end of the chain is always the same... Microsoft Windows.

Patents are just one trick-- there are a lot of other ones, like keeping key .NET libraries Windows-only. If you're doing Linux, just stay away from .NET.

Re: Only Novell will get sued

mikov — Sun, 18 Oct 2009 03:54:48 +0000

Yeah, and my C compiler is not the same as the one I used in the 1990's. And your point is?

Of course Java is generally vulnerable because anybody can get sued for anything in the US. However the existence of .NET does not increase Java's vulnerability to a patent lawsuit from Microsoft specifically. So, the initial claim, that Java's patent vulnerability is similar to Mono's because they are both VMs, is invalid.

Re: Only Novell will get sued

nix — Sat, 17 Oct 2009 23:11:06 +0000

Not quite the same. It's not the in thing anymore.

(The cup has gone cold, one might say.)

Re: Only Novell will get sued

drag — Sat, 17 Oct 2009 22:03:34 +0000

And I suppose that the Java from the 1990's is the same Java that we use today, right? :)

No need

mikov — Sat, 17 Oct 2009 02:30:33 +0000

The font rendering is obvious in Swing applications, in IntelliJ IDEA specifically. It looks different and arguably worse when run under OpenJDK. As I said, that is understandable and perhaps even desirable because it is more consistent with font rendering in native apps, but it does look visibly different from Java applications on Windows. Arguably, that breaks Java's promise of portability.

The more serious SSL problem was seen in an app developed by our company. I am not an expert in SSL or its Java implementation so I can't make head or tails of it. It is in a straight forward call to HttpURLConnection.connect(). This is the stack trace:

javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error:
    java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
    at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
    at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1611)
    at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1574)
    at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1557)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1150)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1127)
    at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:423)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)
    .....
Caused by: java.lang.RuntimeException: Unexpected error: 
   java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
    at sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:75)
    at sun.security.validator.Validator.getInstance(Validator.java:178)
    at sun.security.ssl.X509TrustManagerImpl.getValidator(X509TrustManagerImpl.java:129)
    at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:225)
    at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:270)
    at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:973)
    at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:142)
    at sun.security.ssl.Handshaker.processLoop(Handshaker.java:533)
    at sun.security.ssl.Handshaker.process_record(Handshaker.java:471)
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:904)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1116)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1143)
    ... 31 more
Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
    at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
    at java.security.cert.PKIXParameters.<init>(PKIXParameters.java:120)
    at java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:104)
    at sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:73)
    ... 42 more

Re: Only Novell will get sued

mikov — Fri, 16 Oct 2009 21:09:18 +0000

No.

Considering that Java predates .NET by a significant margin and that Sun and Oracle, no to mention IBM, have their patent portfolios, it is very unlikely that Microsoft can win a patent case against Java. As a matter of fact Python and Perl also predate .NET by about 10 years.

Microsoft's patents would have to have been filed in the 1980-s, which is very unlikely.

It is actually more plausible to think that .NET violates some Sun Java patents than the other way around.

Re: Only Novell will get sued

AlexHudson — Fri, 16 Oct 2009 20:50:44 +0000

Right, but it's not as simple as that unless you get into the actual specifics of the action.

E.g., "WebXchange alleges that FedEx violates three of its patents in an online system that lets people send print jobs to Kinko's stores." - http://www.techworld.com.au/article/267716/microsoft_file...

Quite possibly FedEx built their system out of standard components that come with Visual Studio. I'm not sure that counts as "being sued for relying on someone else's infringement".

Re: Only Novell will get sued

drag — Fri, 16 Oct 2009 20:43:42 +0000

Yes... Java, LLVM, Perl, Python, etc etc. All those are only slightly less
likely to violate unknown Microsoft patents as Mono itself. There is no
reason why MS needs to limit patents to its own products.

So if your avoiding Mono to avoid patents your not being logical, really.

Although I would avoid using anything not covered by the EMCA standards that
Microsoft published.

Re: Only Novell will get sued

HenrikH — Fri, 16 Oct 2009 15:47:54 +0000

>I'd love to see some citation for being sued by the patent holder for being the beneficiary of patent infringement in someone else's software though.

A company called WebXchange sued three companies because the used Visual Studio: http://news.cnet.com/8301-13860_3-10099745-56.html?part=r...

I also recall several companies getting sued due to patents in MS SQL Server a few years ago.

Monomania (Tux Deluxe)

epa — Fri, 16 Oct 2009 12:29:51 +0000

The distinction between a promise-not-to-sue and a licence is the main reason why some (such as the FSF) are unhappy with Microsoft's 'community promise' not to sue over the software patents they hold that apply to C# and the CLR. Whereas a licence is generally irrevocable unless it states otherwise, you could possibly get out of a promise-not-to-sue by passing on the patents to another company which is not bound by your promise.

Indeed, promises in general are not binding; if I promise to pay you a dollar tomorrow, you have no recourse if I break it. However the doctrine of promissory estoppel means that if I promise to allow use of certain property rights and you take action based on that promise, I cannot then break the promise and sue you. IANAL, so that's the limit of my knowledge, but I do know that there is a difference between a promise and a licence, and while it may be legalese, it's the kind of legalese that makes a difference in some cases.

(So, then, back to the 'community promise' offered by MS to people who are not Novell customers: I don't share the FSF's concerns, since it seems to me pretty hard to persuade a court that you can get out of it, even if the patents were transferred to a third party. I would expect a patent suit from a third party to be estopped just as much. But the FSF's lawyers take a more cautious view and think that only a true licence will make sure of this. (Then again, I was happy to use and distribute Mono even before this 'community promise', since there is plenty of software which implements software patents, some of which are even held by Microsoft, and I see no reason to pre-emptively cringe and go begging to patent-holders in advance for every program we want to write. Let them sue, if they dare.))

Monomania (Tux Deluxe)

pebolle — Fri, 16 Oct 2009 12:10:14 +0000

> the promise not to sue is offered by MS, but not tied to the software (it's not a license)

0) Why isn't it a license?

1) In case the fact that this document (declaration? whatever?) is called a promise not to sue is relevant for the answer to that question: the GPL could also be rewritten as a promise not to sue (with sufficient abuse of legalese) without changing its effects. I'd say that (hypothetical) GPL rewritten as a promise not to sue should still be regarded as a license.

Actually, I'd think that in general a lot of contracts, licenses, etc. can be rewritten negatively (eg, as a promise not to sue): that would not change their effects (but the parties involved are then forced to use documents with really, really ugly legalese).

Monomania (Tux Deluxe)

AlexHudson — Fri, 16 Oct 2009 10:43:35 +0000

I'm sure I don't need to point out the error on logic in the above :), but it's irrelevant anyway: the promise not to sue is offered by MS, but not tied to the software (it's not a license). MS say "we won't sue Novell's customers" - where Novell got "their" copy of Mono from is inconsequential, the promise doesn't apply to them.

Monomania (Tux Deluxe)

BeS — Fri, 16 Oct 2009 09:03:26 +0000

>It's well known that they covered each other's customers.
>The claim above that I don't think can be supported is that Novell themselves are covered by that agreement.

Let's try a syllogism:
Every customer from Novell and Microsoft is covered by the agreement. So if someonne gets Mono from Novell he is save, right? From whom does Novell gets theri Mono they advance? It's the Novell version, right? So Novell uses a Novell version and a Novell version is covered by the agreement for everyone who uses is, Novell included.

Re: Only Novell will get sued

AlexHudson — Fri, 16 Oct 2009 08:12:00 +0000

Because for the most part they work exactly the same way, and patents do not cover specific implementations - they cover the more general idea (speaking simplistically).

Thus, if Mono were to be sued, it would be either over some minor feature so inscrutable it wouldn't be a huge loss, or it would be over something so major it would inevitably cover many other programs - Java just happens to be the obvious candidate.

After all, if Java had been free earlier the Kodak suit would have been hugely depressing for free software. I'm staggered people would be willing to give that up without a fight; that would just show patent trolls that the community can be easily cowed. Sad :(

Monomania (Tux Deluxe)

AlexHudson — Fri, 16 Oct 2009 08:06:03 +0000

No, what I was saying was simpler than that.

The agreement is public knowledge, and it's on Novell's and Microsoft's website. It's well known that they covered each other's customers.

The claim above that I don't think can be supported is that Novell themselves are covered by that agreement. I've never read anyone before seriously suggest that, and that situation would definitely put them in trouble with their obligations under the GPL.

Monomania (Tux Deluxe)

sitaram — Fri, 16 Oct 2009 06:09:09 +0000

I guess I have a new (or yet another!) hero...

I just hope Mandriva doesn't get these "install mono by default" ideas, but fortunately a "no bloat" objective (as espoused by LXDE and such) is sufficient garlic, so there's always be those distros to fall back on.

No need

rahulsundaram — Fri, 16 Oct 2009 04:42:28 +0000

Perhaps you can file bug reports or let me know the application names.

No need

mikov — Fri, 16 Oct 2009 04:17:59 +0000

I remember seeing two problems. One was related to SSL, and the other to font rendering. The latter is understandable, naturally, but it still should be acknowledged. The former is a bit more troublesome - alas I didn't have time to investigate it, but I noted that the application wouldn't work.

No need

rahulsundaram — Fri, 16 Oct 2009 03:18:04 +0000

OpenJDK in Fedora is certified by TCK to be 100% compliant. So if there are problems with applications, either the application is buggy or tck needs more tests

http://java.dzone.com/news/red-hats-icedtea-project-power

Monomania (Tux Deluxe)

rahulsundaram — Fri, 16 Oct 2009 03:14:37 +0000

If you want to exclude any packages, you can do something like exclude=foo* in /etc/yum.conf. I am not sure I understand the benefit of short circuiting the dep resolver.

Monomania (Tux Deluxe)

dmarti — Fri, 16 Oct 2009 01:52:58 +0000

Sure, you don't _need_ the antipackage, but it converts something you have to check for into something that fails.

No need

mikov — Fri, 16 Oct 2009 01:34:13 +0000

?? There is a fully open source Java version right now - it is called OpenJDK. It is available in Debian main - is there a stringer guarantee for being free? :-) :-)

BTW, I am have found some minor incompatibilities, but it is almost certainly good enough.