Monomania (Tux Deluxe)
But my basic issue with the Microsoft Community Promise is that Miguel doesn't have to depend on it like everyone else does. Miguel's employer, Novell, has a patent agreement with Microsoft that exempts Mono users from Microsoft patent aggression, so long as you get Mono from Novell. Miguel takes pains to point this out. This is not a level playing field, or software freedom for all. This is a preferred supplier trying to pretend there is no problem. Sure there isn't a problem, for them. If it isn't good enough for Miguel, why is it good enough for other developers?"
Posted Oct 15, 2009 15:13 UTC (Thu)
by laurencevde (guest, #61381)
[Link] (7 responses)
Mono can most probably be put in MS's definition of "clone products"...
http://www.microsoft.com/interop/msnovellcollab/patent_ag...
Posted Oct 15, 2009 16:09 UTC (Thu)
by leomilano (guest, #32220)
[Link] (6 responses)
Posted Oct 15, 2009 16:16 UTC (Thu)
by proski (subscriber, #104)
[Link] (5 responses)
The dependency of GNOME on Mono is greatly exaggerated.
Posted Oct 15, 2009 20:25 UTC (Thu)
by dmarti (subscriber, #11625)
[Link] (4 responses)
Posted Oct 16, 2009 0:04 UTC (Fri)
by proski (subscriber, #104)
[Link] (3 responses)
Posted Oct 16, 2009 1:01 UTC (Fri)
by drag (guest, #31333)
[Link] (2 responses)
When installing software use aptitude and when you install a bunch of crap
For custom kernels you use kernel-package and you can easily create your
If you want to you can compile everything from source using the dpkg/apt-
Posted Oct 16, 2009 1:52 UTC (Fri)
by dmarti (subscriber, #11625)
[Link] (1 responses)
Posted Oct 16, 2009 3:14 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Oct 15, 2009 17:35 UTC (Thu)
by AlexHudson (guest, #41828)
[Link] (45 responses)
If Mono has a patent problem, it's going to be Novell who get sued. Putting in place an agreement which ensures customers don't get sued (by one party) - not particularly fair, but not particularly a freedom problem. Novell are still at risk.
Arguing that Mono should be put in a "restricted" category doesn't make any sense. It's not like the patents at issue (which never seem to be properly defined) aren't going to cover other software.
Posted Oct 15, 2009 17:52 UTC (Thu)
by dlang (guest, #313)
[Link] (9 responses)
Posted Oct 15, 2009 18:08 UTC (Thu)
by AlexHudson (guest, #41828)
[Link] (6 responses)
Posted Oct 15, 2009 23:24 UTC (Thu)
by coriordan (guest, #7544)
[Link] (5 responses)
So the agreement is useless, MS owns a heap of patents on this thing, and Novell and de Icaza are trying to convince us we should use it as the foundation for our software.
How is there not a problem there?
Maybe we can't avoid all potentially dangerous software, but this stack's a real stinker. We could at least avoid this one.
Posted Oct 16, 2009 8:06 UTC (Fri)
by AlexHudson (guest, #41828)
[Link] (4 responses)
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.
Posted Oct 16, 2009 9:03 UTC (Fri)
by BeS (guest, #43108)
[Link] (3 responses)
>It's well known that they covered each other's customers. Let's try a syllogism:
Posted Oct 16, 2009 10:43 UTC (Fri)
by AlexHudson (guest, #41828)
[Link] (2 responses)
Posted Oct 16, 2009 12:10 UTC (Fri)
by pebolle (guest, #35204)
[Link] (1 responses)
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).
Posted Oct 16, 2009 12:29 UTC (Fri)
by epa (subscriber, #39769)
[Link]
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.))
Posted Oct 25, 2009 8:10 UTC (Sun)
by malor (guest, #2973)
[Link] (1 responses)
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.
Posted Oct 25, 2009 8:17 UTC (Sun)
by malor (guest, #2973)
[Link]
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.
Posted Oct 15, 2009 17:55 UTC (Thu)
by PO8 (guest, #41661)
[Link] (34 responses)
So as far as I can tell it's not merely Novell's problem. Until Microsoft officially licenses its Mono-related technologies without restriction to the open source community (and for me the "Community Promise" doesn't count), I will personally be keeping Mono at arm's length.
Honestly, it isn't proving very hard for me to live without C# and .Net in my open source work anyhow.
Posted Oct 15, 2009 18:07 UTC (Thu)
by AlexHudson (guest, #41828)
[Link] (33 responses)
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. (if you're "practising the patent" directly, it doesn't matter what language you've implemented it in - going to e.g. Python doesn't get you out of that jail).
Posted Oct 15, 2009 20:20 UTC (Thu)
by ncm (guest, #165)
[Link] (21 responses)
Posted Oct 15, 2009 20:48 UTC (Thu)
by drag (guest, #31333)
[Link] (20 responses)
Luckily the next java version will be fully open source, I believe.
Posted Oct 16, 2009 1:34 UTC (Fri)
by mikov (guest, #33179)
[Link] (19 responses)
Posted Oct 16, 2009 3:18 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (18 responses)
Posted Oct 16, 2009 4:17 UTC (Fri)
by mikov (guest, #33179)
[Link] (17 responses)
Posted Oct 16, 2009 4:42 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (16 responses)
Posted Oct 17, 2009 2:30 UTC (Sat)
by mikov (guest, #33179)
[Link] (15 responses)
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:
Posted Oct 22, 2009 9:01 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (14 responses)
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"
Posted Oct 22, 2009 16:47 UTC (Thu)
by nye (subscriber, #51576)
[Link] (1 responses)
Posted Oct 22, 2009 17:50 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link]
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)
Posted Oct 22, 2009 16:58 UTC (Thu)
by mikov (guest, #33179)
[Link] (11 responses)
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.
Posted Oct 22, 2009 17:28 UTC (Thu)
by nye (subscriber, #51576)
[Link] (1 responses)
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.
Posted Oct 22, 2009 18:27 UTC (Thu)
by mikov (guest, #33179)
[Link]
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.
Posted Oct 22, 2009 17:44 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (8 responses)
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.
Posted Oct 22, 2009 18:16 UTC (Thu)
by mikov (guest, #33179)
[Link] (7 responses)
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)
Posted Oct 22, 2009 18:54 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (6 responses)
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
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
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
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/
> About the Java font rendering bugs - I am not aware of those, but I
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.
Posted Oct 22, 2009 19:48 UTC (Thu)
by mikov (guest, #33179)
[Link] (5 responses)
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
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
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
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.
Posted Oct 22, 2009 20:28 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (4 responses)
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
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
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
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
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
The AA settings let you choose a point between the two curbs on
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)
Posted Oct 23, 2009 0:48 UTC (Fri)
by mikov (guest, #33179)
[Link] (3 responses)
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
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
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
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
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
You are missing my point, perhaps because we are talking about two separate issues. These are conflicting goals:
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.
Posted Oct 23, 2009 1:13 UTC (Fri)
by mikov (guest, #33179)
[Link] (1 responses)
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?
Posted Oct 23, 2009 6:04 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link]
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.
Posted Oct 23, 2009 6:16 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link]
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
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)
Posted Oct 16, 2009 1:30 UTC (Fri)
by mikov (guest, #33179)
[Link] (8 responses)
Posted Oct 16, 2009 8:12 UTC (Fri)
by AlexHudson (guest, #41828)
[Link] (7 responses)
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 :(
Posted Oct 16, 2009 20:43 UTC (Fri)
by drag (guest, #31333)
[Link] (6 responses)
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
Posted Oct 16, 2009 21:09 UTC (Fri)
by mikov (guest, #33179)
[Link] (5 responses)
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.
Posted Oct 17, 2009 22:03 UTC (Sat)
by drag (guest, #31333)
[Link] (4 responses)
Posted Oct 17, 2009 23:11 UTC (Sat)
by nix (subscriber, #2304)
[Link]
(The cup has gone cold, one might say.)
Posted Oct 18, 2009 3:54 UTC (Sun)
by mikov (guest, #33179)
[Link] (1 responses)
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.
Posted Oct 19, 2009 4:57 UTC (Mon)
by jamesh (guest, #1159)
[Link]
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.
Posted Oct 18, 2009 22:42 UTC (Sun)
by cmccabe (guest, #60281)
[Link]
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.
C.
Posted Oct 16, 2009 15:47 UTC (Fri)
by HenrikH (subscriber, #31152)
[Link] (1 responses)
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.
Posted Oct 16, 2009 20:50 UTC (Fri)
by AlexHudson (guest, #41828)
[Link]
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".
Posted Oct 16, 2009 6:09 UTC (Fri)
by sitaram (guest, #5959)
[Link]
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.
Monomania (Tux Deluxe)
large list of excluded products (gross simplification):
Clone products that are created(or got new functionality) after that
covenant was put in effect, or are called Wine, OpenXchange, StarOffice or
OpenOffice.
Hosted Office-applications, gaming-stuff, business-apps, mail-servers, and
"unified communications".
Monomania (Tux Deluxe)
There is no need to switch to KDE to avoid Mono. All you need to do is
Monomania (Tux Deluxe)
yum remove "mono*"
Feel free to borrow and work from the antipackages--the general idea is to install "no-mono" to make the package manager warn you if you bring in something that depends on it. (Also antipackages for no-java, no-python, to be fair.)
Monomania (Tux Deluxe)
Monomania (Tux Deluxe)
Monomania (Tux Deluxe)
compile your kernel.
then make sure that mono is not among it. A antipackage would be useful for
that if you want to be lazy, which is fine, but you don't need it.
own custom deb packages. Very simple and it does not break any Debian
systems like automatically updating initrds, automatic bootloader
configuration and stuff like that.
get stuff, it is just that people don't normally do it because there is no
advantage to doing it most of the time.
Sure, you don't _need_ the antipackage, but it converts something you have to check for into something that fails.
Monomania (Tux Deluxe)
Monomania (Tux Deluxe)
Monomania (Tux Deluxe)
Monomania (Tux Deluxe)
Monomania (Tux Deluxe)
Monomania (Tux Deluxe)
Monomania (Tux Deluxe)
Monomania (Tux Deluxe)
>The claim above that I don't think can be supported is that Novell themselves are covered by that agreement.
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.Monomania (Tux Deluxe)
Monomania (Tux Deluxe)
Monomania (Tux Deluxe)
Monomania (Tux Deluxe)
Crap, I should have included this quote in the post above:Monomania (Tux Deluxe)
Re: Only Novell will get sued
Re: Only Novell will get sued
No need
No need
No need
BTW, I am have found some minor incompatibilities, but it is almost certainly good enough.
No need
No need
No need
No need
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
No need
No need
No need
No need
No need
No need
No need
No need
No need
> 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.
> with disabled anti-aliasing and compare. These are facts.
> 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?
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_...
> 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
> 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)
> proved subjective time and time again
>> 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.
> 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).
No need
> any desktop-related problems are non essential.
http://www.stixfonts.org/
> 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.
> by definition subjective then there is nothing to discuss.
> a small two-color display should be a solved problem.
> of anti-aliasing.
http://damieng.com/blog/2007/06/13/font-rendering-philoso...
No need
> 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]
> the level expected today, or it isn't, and comparisons of font rendering
> are irrelevant
> rendering you think is obviously better is not acceptable either. So
> don't pretend it's an objective statement.
> 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.
> 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.
> 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)
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.
No need
http://antigrain.com/research/font_rasterization/
No need
No need
> samples in a blog post. I don't care what they say. I am talking about
> delivering working products to paying customers... :-)
> 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.
Re: Only Novell will get sued
Re: Only Novell will get sued
Re: Only Novell will get sued
likely to violate unknown Microsoft patents as Mono itself. There is no
reason why MS needs to limit patents to its own products.
Microsoft published.
Re: Only Novell will get sued
Re: Only Novell will get sued
Re: Only Novell will get sued
Re: Only Novell will get sued
Re: Only Novell will get sued
Re: Only Novell will get sued
Re: Only Novell will get sued
Re: Only Novell will get sued
Monomania (Tux Deluxe)