The judge says that "XS4ALL does not have a conveyance obligation".
Now, XS4ALL is not an U.S. based ISP, so certain concepts like that of common carrier status may not apply. But such things used to apply in the U.S., even if they don't apply today.
The reason this isn't a victory is that it essentially declares that the ISP may transport ("convey") whatever data it pleases.
Well, it is a privately owned company, and I can see some merit to the argument that what it does with its resources is its own business.
But now apply the same logic to all ISPs, particularly the large ones, in light of the behavior of the media. That's right, folks: this ruling means that ISPs have the right to refuse to transmit any data they see fit. In short, they have the right to censor. After all, there's nothing that prevents them from selectively filtering.
How would you like it if an ISP decided that it didn't want to bother transiting any Slashdot traffic? Or Kuro5hin? Or any non-mainstream web source? What if they start dropping data based on the content of the data itself? Think it can't happen?
You say you could go to another ISP? Tell us that when the only ISPs left are AOL/TW and AT&T (the former, at least, has a very large interest in being selective about what you, the audience, see).
This may be a "victory" in the fight against spam, but it has ramifications that are so bad that I'll take the spam, thank you.
The standard X11 protocol requires 1-bit bitmapped fonts and the XFree team couldn't just up and break it so fundamentally, so they did XRender. While they were at it, they implimented things like alpha-blending (Which is pretty much needed for proper AA anyway) and some other things, but I don't know specifics.
I haven't looked at the X protocol itself, but the Xlib call to draw text on the screen is XDrawString() and XDrawText(). In both cases, you use a GC specifier, and the GC itself is what contains which font you want to use to perform the text drawing operation.
While the documentation may specify how exactly fonts are drawn, the GC is an opaque data type. That implies that it should be possible to change its internal representation on the server without any client-side consequences (I'm assuming that the GC really is a server side construct and not an Xlib construct).
But if you must make client-side changes in order to support antialiased fonts, there's only one proper place to do it: Xlib itself. At least then you'll automatically get antialiased font support in all of your toolkits on that client, without having to change a thing in those toolkits (because you can change the Xlib implementations of XLoadFont(), XDrawString(), etc., as needed).
Look, my comment is in no way a criticism of RENDER. I can see lots of advantages to having that extension, and it's excellent work.
What I'm talking about is fonts, and only fonts.
Antialiased text might be an interesting and cool use of the RENDER extension, but it's not a particularly good use, and here's why:
Every toolkit for which you want antialiased text must be compiled with Xft support (or whatever client-side font handler supports the RENDER extension).
Every client machine on which you're running an X application must not only have the above mentioned toolkits, but must also have a set of fonts to be used by the client.
You now have to concern yourself with whether or not the fonts are all the same on all of the client machines you're going to use.
If you want to use a font on multiple clients, you have to install it on all of those clients, instead of simply sticking it on the font server.
Since there's no guarantee that the X server supports the RENDER extension, every client (or toolkit that the client uses -- this could be included in Xft, for instance) has to have fallback code which uses the standard X font calls in case the RENDER extension is unavailable. But this is a big problem, because now you have to concern yourself with whether your font metrics (among other things) for your standard server-side fonts are the same as the ones for the fonts on the client, since the font set being used by the X server is different than the font set being used by the client.
Proprietary toolkits and clients (particularly those that are statically linked) gain no benefit at all -- they use non-antialiased fonts as usual.
All the world isn't Unix, you know. What are you going to do about those X clients that are running on systems on which your toolkits won't even compile (VMS comes to mind, outdated as it may be)? X isn't just supposed to be network-based, it's supposed to be platform independent, but this method of font handling is anything but.
The end result that I see is that client side font rendering doesn't give you any real advantages over server side rendering, with the sole exception (that I can think of, at any rate) that the client will know that the font being displayed on the screen and the font being used for printing will have the same metrics and appearance. Other than that, you take a performance hit (client has to upload the font to the server every time it wants to use it, the same font will be uploaded multiple times by multiple clients or at least multiple toolkits, since it's possible for the toolkit to cache the font locally in shared memory or something. I'm making certain assumptions about the implementation here, though), you get inconsistent font handling and rendering (what says that toolkit A will use the same font set as toolkit B?), you'll probably use a lot more in the way of server resources if you're running clients on lots of different machines, and worst of all your desktop looks really inconsistent. The only time you don't really run into most of this is when the client and server are on the same machine. While I'll admit that this is most of the time, if you're going to give up some of the advantages of a networked display system why stop there?
It seems to me that this way of handling fonts does exactly the same thing for fonts that client-side GUI toolkits does for look and feel: causes a ton of confusion, makes it difficult to get a consistent look and feel on the desktop, and causes a lot of waste in the process.
So the bottom line is that, as far as I can see, what we really need is the RENDER extension and server-side antialiased font handling.
(We also need server-side toolkits, but that's a discussion for another day).
I've asked this before, but nobody has given me a terribly good answer yet.
Why isn't font rendering done properly in the X server itself, where font rendering originally was done? Why must it be done client side?
I mean, the X server already knows what kind of visual you're trying to render to, so it's really just a question of getting the X server to pick up the necessary font information (transparency information at the edges of the letters if you insist on the X server itself not understanding how to render fonts). And the types used for the font rendering calls are all opaque anyway, so it shouldn't matter whether or not the font structure in the GC (on the server) stores additional information about the font being rendered, right?
All it would take in addition to the improved font rendering code in the X server is the definition of a new font server protocol that allows the transmission of more than just bitmap information to the X server from the font server and you'd be done, right?
So why isn't this being done instead of these client-side hacks that require magic rendering extensions (which are quite cool in and of themselves, but why should the client have to have a full set of fonts stored locally in order to do antialiased text?) ? The biggest advantage of this scheme by far is that you don't have to have any magic support for antialiased fonts in your toolkits: you get antialiased fonts for everything no matter what toolkit it's using (even Athena widgets would have antialiased text if the antialiased font rendering were done entirely server-side).
Or is this already what's being done, but I somehow missed it?
Why not just automatically flunk the student if you catch him cheating and can prove he did it?
I mean, by expelling him you remove his opportunity to learn from the experience. By flunking him you force him to take the class again, during which time he might actually learn the material.
If all the instructors did this and got the necessary support from the university, the student would eventually drop out on his own if he kept cheating and getting caught.
The real problem seems to be spineless school administrators who don't have the guts to tell the kid's parents to go somewhere else if they don't like little Johnny being flunked for cheating.
(For those that don't get the Niven reference, water is deadly to the Martians in the Known Space series, and one of the characters in Protector used this to good advantage).
I won't believe that any company has lost any money to piracy until they explicitly put that amount of money as an itemized loss on their quarterly balance sheet.
Until then, I have to consider it a sham. I mean, in real life, if a business really does take a loss on something, they report it as such on their quarterly financial statement.
Their staff is there to listen to your comments and respond to them. They do take your voice into account.
Perhaps. But I'd bet it's not in the way you'd expect.
My bet is that they "listen" in order to figure out what's on the minds of the people in question and then use marketing techniques to later convince the people that they're getting something close to what they want, when in reality the administration is just doing what its corporate masters are telling it to.
Hell, they might even feed that data back to their corporate masters so that those corporations can use it in their marketing efforts.
In short, even if they're listening, it's probably not for doing what the people actually want.
This is the reason having Mono at the heart of Gnome would be a good idea. Base it on the CLI and suddenly any language that is ".Net-enabled" is usable under Gnome.
Yeah, right.
Look, there's only one feature that Microsoft needs to add to the VM in order to completely break this supposed interoperability golden egg: the ability to make arbitrary, native Win32 calls.
Once they do that (and you know there's going to be demand for it), the game's over -- they win.
It is unlikely that a surprise patent is going to bite you 5 years down the line.
You've gotta be kidding. With the way the patent office is granting patents on ideas that are not only obvious, but which also have plenty of prior art behind them?
In that kind of environment, it doesn't matter whether or not a technique you use is obvious, nor does it matter that it's been in use for some time. The patent office will happily issue a patent against it.
Your citations of the law make no difference. For one thing, the patent office has been ignoring the law when it comes to issuing patents. For another, the mere threat of patent litigation is going to be enough to cause a small company like Ximian to fold, because patent litigation (like any litigation beyond small claims court) is horrendously expensive.
You'd have to be an idiot to bank on someone like Microsoft not coming after you and others for patent violation, no matter how they obtained their patent(s) or how obvious/popular the techniques in question are. But that's exactly what Miguel is counting on.
I can't think of a better example than Mono to use to demonstrate that when deciding what kinds of architectures, protocols, and tools to use for an open source project, you're better off choosing the best, and not what you think the most popular will be.
I have a strong suspicion that.NET on the server side will be easy to do under Linux (with the exception of authentication, which will be strongly protected by patents), but.NET on the client side (which is what Miguel is working on) will prove impossible. That's because Microsoft will build Win32-specific things into their.NET client libraries. Or have we already forgotten what they did with Java??
He's got a point. If you need a database, and losing even a one email could mean the difference in thousands of dollars in fines for violating your service agreements with your client's, you need another big pocketed company to blame when it's the database fault, and not yours.
That won't help you when the chips are down. Either you can word the service agreement so that you can absolve yourself of blame in the event of hardware or software failure (in which case the database you're using won't make a bit of difference), or you are going to be in violation of your service agreements no matter whose fault it really is (as long as it's not the customer's). Your customers simply aren't going to care whether it's a problem with Oracle or a problem with you: they're paying you, not Oracle, so if you happen to have a database problem on your end that causes the service agreement to be violated, the customer will blame you, period.
Seems to me that the ability to shift the blame to someone else is only useful to middle managers who are trying to climb the corporate ladder, not real businesses with real, paying customers. Blaming others for problems that are causing pain to your customers only makes you look stupid in the eyes of your customers. All the customer cares about is that you get the problem(s) fixed -- no matter whose "fault" it is.
However, diseases DO NOT kill off 100% of anything -- being too deadly is an evolutionary dead end.
Yes, but the history of the world is full of evolutionary dead ends. Just because something is an evolutionary dead end doesn't mean it won't happen. Quite the contrary: evoluationary dead ends are the norm. It's the stuff that survives evolution that is unusual, and the only reason we don't think of it that way is that the stuff that has survived evolution is generally what we find in our environment.
No, a disease that can wipe out the species is very possible, and is something that should be factored into the Drake equation.
4-6 kilowatts is not terrible. I'm guessing you're calculating by straight extrapolation. Mistake. Most power is lost at connections between two different materials, and there aren't any in this design.
If this is the case, why does going to a smaller process (0.13u versus 0.18u, for instance) yield such a large drop in power consumption by the same chip design running at the same clock speed?
Intel Guy: Yeah, Yamhill. Stands for "Yet Another Molehill"... as in what your processor is.
Why doesn't X just do the right thing with fonts?
on
Xft Support For Mozilla
·
· Score: 3, Interesting
This bit about having to render fonts using a completely different mechanism than what's already provided by X is complete nonsense, IMHO. Why doesn't X font rendering simply do the right thing?
I can understand that X fonts originally were simple bitmaps that got rendered directly to the screen. But the X server knows what kind of visual is being rendered to, so I don't see why it can't render in a more sophisticated manner when drawing to a visual with at least 16 bits worth of color depth.
Were the original designers of the font rendering mechanism so braindead as to specify that all fonts forevermore would be bitmaps??? What the hell for???
As for the X font protocol, that's easy: design an upgraded protocol that the X server can also deal with, that's used to transmit font information along with transparency information. Or use a separate channel for the transparency information and keep the bitmap protocol the way it is.
But either way, font rendering belongs in the server, and having the client do it is complete nonsense.
I mean, the GC is an opaque data type, as is the Font, right? So what's to prevent you from having a mask with a depth greater than 1, which is created when you use XSetFont() with a font that has alpha information?
Loki all but proves that building a business around
porting games from Windows to Linux doesn't work.
But perhaps writing games for Linux and porting
them to Windows might?
Would it be easier to write the game for Linux and
then do the port to Windows? Which is more
difficult, going from Windows to Linux or from
Linux to Windows? I'd imagine Linux -> Windows
is easier to do since you'll be using a set of
libraries that are more likely to be cross-platform
than if you started with Windows.
I was hoping someone would finally come up with a good method to use in lunzip (see this for more details. In short, it's a superior compression utility, at least for certain jobs, like prepping your computer for the FBI).
Using blocking patents is not a logical strategy for Microsoft. In the first place it might well involve an anti-trust violation, particularly now that the courts have rulled that Microsoft is a monopoly.
Yeah, and we've all seen for ourselves all of the nasty, horrible things that happen to Microsoft as a result of anti-trust action. Like... er... umm... well, I'm sure there's been something!
The article says that SGI has "transferred" the patents to Microsoft. This implies that SGI sold Microsoft the patents themselves, not merely a license to use them.
I mean, XML is the solution to all our problems, right?
</SARCASM>
Re:I'll never tourch RPM again if I have too
on
OpenPKG 1.0 Released
·
· Score: 2
Ports (and portupgrade) are not only about source. Ports (and portupgrade) can handle binary-only packages, and handle very well VMWare (/usr/ports/emulators/vmware), Opera (/usr/ports/www/linux-opera), etc.
Ah, cool. Ports allows you to determine what piece of software a file belongs to and things like that? If so, then it sounds like a nice solution.
Re:I'll never tourch RPM again if I have too
on
OpenPKG 1.0 Released
·
· Score: 2
Since FreeBSD can run the huge majority of linux applications that I need/want, i have no need to get into RPM-hell again.
If I need to upgrade a system I use cvsup to apply the necessary patches to my source tree and make the world. If I want to update applications, I cvsup my ports tree and run portupgrade. There's nothing easier and it's very rare anything goes wrong.
Very good. So what do you do if you want to install binary-only packages that don't have corresponding source (VMWare comes to mind as one such package, though it might not be ported to FreeBSD)?
Ah. I see. You just install it and track it manually.
Well, as a system administrator, that's not good enough for me. The reason I like to use a package management system is that it makes it EASY to manage the huge number of files on my system. If I'm not sure what bit of software a particular file belongs to, I can query the package manager (not every file has a manpage, you know). Can you do that with ports?
Ports is an awesome way to keep your system up to date, but don't confuse it with a good package manager. They serve different needs.
Slashdot Mirror
Now, XS4ALL is not an U.S. based ISP, so certain concepts like that of common carrier status may not apply. But such things used to apply in the U.S., even if they don't apply today.
The reason this isn't a victory is that it essentially declares that the ISP may transport ("convey") whatever data it pleases.
Well, it is a privately owned company, and I can see some merit to the argument that what it does with its resources is its own business.
But now apply the same logic to all ISPs, particularly the large ones, in light of the behavior of the media. That's right, folks: this ruling means that ISPs have the right to refuse to transmit any data they see fit. In short, they have the right to censor. After all, there's nothing that prevents them from selectively filtering.
How would you like it if an ISP decided that it didn't want to bother transiting any Slashdot traffic? Or Kuro5hin? Or any non-mainstream web source? What if they start dropping data based on the content of the data itself? Think it can't happen?
You say you could go to another ISP? Tell us that when the only ISPs left are AOL/TW and AT&T (the former, at least, has a very large interest in being selective about what you, the audience, see).
This may be a "victory" in the fight against spam, but it has ramifications that are so bad that I'll take the spam, thank you.
I haven't looked at the X protocol itself, but the Xlib call to draw text on the screen is XDrawString() and XDrawText(). In both cases, you use a GC specifier, and the GC itself is what contains which font you want to use to perform the text drawing operation.
While the documentation may specify how exactly fonts are drawn, the GC is an opaque data type. That implies that it should be possible to change its internal representation on the server without any client-side consequences (I'm assuming that the GC really is a server side construct and not an Xlib construct).
But if you must make client-side changes in order to support antialiased fonts, there's only one proper place to do it: Xlib itself. At least then you'll automatically get antialiased font support in all of your toolkits on that client, without having to change a thing in those toolkits (because you can change the Xlib implementations of XLoadFont(), XDrawString(), etc., as needed).
What I'm talking about is fonts, and only fonts.
Antialiased text might be an interesting and cool use of the RENDER extension, but it's not a particularly good use, and here's why:
The end result that I see is that client side font rendering doesn't give you any real advantages over server side rendering, with the sole exception (that I can think of, at any rate) that the client will know that the font being displayed on the screen and the font being used for printing will have the same metrics and appearance. Other than that, you take a performance hit (client has to upload the font to the server every time it wants to use it, the same font will be uploaded multiple times by multiple clients or at least multiple toolkits, since it's possible for the toolkit to cache the font locally in shared memory or something. I'm making certain assumptions about the implementation here, though), you get inconsistent font handling and rendering (what says that toolkit A will use the same font set as toolkit B?), you'll probably use a lot more in the way of server resources if you're running clients on lots of different machines, and worst of all your desktop looks really inconsistent. The only time you don't really run into most of this is when the client and server are on the same machine. While I'll admit that this is most of the time, if you're going to give up some of the advantages of a networked display system why stop there?
It seems to me that this way of handling fonts does exactly the same thing for fonts that client-side GUI toolkits does for look and feel: causes a ton of confusion, makes it difficult to get a consistent look and feel on the desktop, and causes a lot of waste in the process.
So the bottom line is that, as far as I can see, what we really need is the RENDER extension and server-side antialiased font handling. (We also need server-side toolkits, but that's a discussion for another day).
Why isn't font rendering done properly in the X server itself, where font rendering originally was done? Why must it be done client side?
I mean, the X server already knows what kind of visual you're trying to render to, so it's really just a question of getting the X server to pick up the necessary font information (transparency information at the edges of the letters if you insist on the X server itself not understanding how to render fonts). And the types used for the font rendering calls are all opaque anyway, so it shouldn't matter whether or not the font structure in the GC (on the server) stores additional information about the font being rendered, right?
All it would take in addition to the improved font rendering code in the X server is the definition of a new font server protocol that allows the transmission of more than just bitmap information to the X server from the font server and you'd be done, right?
So why isn't this being done instead of these client-side hacks that require magic rendering extensions (which are quite cool in and of themselves, but why should the client have to have a full set of fonts stored locally in order to do antialiased text?) ? The biggest advantage of this scheme by far is that you don't have to have any magic support for antialiased fonts in your toolkits: you get antialiased fonts for everything no matter what toolkit it's using (even Athena widgets would have antialiased text if the antialiased font rendering were done entirely server-side).
Or is this already what's being done, but I somehow missed it?
Until then, quit wasting our time.
I mean, by expelling him you remove his opportunity to learn from the experience. By flunking him you force him to take the class again, during which time he might actually learn the material.
If all the instructors did this and got the necessary support from the university, the student would eventually drop out on his own if he kept cheating and getting caught.
The real problem seems to be spineless school administrators who don't have the guts to tell the kid's parents to go somewhere else if they don't like little Johnny being flunked for cheating.
And if the antitrust case lasts longer than three years? Does Microsoft then win by default as their opponent disappears in a puff of blue smoke?
(For those that don't get the Niven reference, water is deadly to the Martians in the Known Space series, and one of the characters in Protector used this to good advantage).
Until then, I have to consider it a sham. I mean, in real life, if a business really does take a loss on something, they report it as such on their quarterly financial statement.
Perhaps. But I'd bet it's not in the way you'd expect.
My bet is that they "listen" in order to figure out what's on the minds of the people in question and then use marketing techniques to later convince the people that they're getting something close to what they want, when in reality the administration is just doing what its corporate masters are telling it to.
Hell, they might even feed that data back to their corporate masters so that those corporations can use it in their marketing efforts.
In short, even if they're listening, it's probably not for doing what the people actually want.
Cynical? Who, me?
Yeah, right.
Look, there's only one feature that Microsoft needs to add to the VM in order to completely break this supposed interoperability golden egg: the ability to make arbitrary, native Win32 calls.
Once they do that (and you know there's going to be demand for it), the game's over -- they win.
You've gotta be kidding. With the way the patent office is granting patents on ideas that are not only obvious, but which also have plenty of prior art behind them?
In that kind of environment, it doesn't matter whether or not a technique you use is obvious, nor does it matter that it's been in use for some time. The patent office will happily issue a patent against it.
Your citations of the law make no difference. For one thing, the patent office has been ignoring the law when it comes to issuing patents. For another, the mere threat of patent litigation is going to be enough to cause a small company like Ximian to fold, because patent litigation (like any litigation beyond small claims court) is horrendously expensive.
You'd have to be an idiot to bank on someone like Microsoft not coming after you and others for patent violation, no matter how they obtained their patent(s) or how obvious/popular the techniques in question are. But that's exactly what Miguel is counting on.
I can't think of a better example than Mono to use to demonstrate that when deciding what kinds of architectures, protocols, and tools to use for an open source project, you're better off choosing the best, and not what you think the most popular will be.
I have a strong suspicion that .NET on the server side will be easy to do under Linux (with the exception of authentication, which will be strongly protected by patents), but .NET on the client side (which is what Miguel is working on) will prove impossible. That's because Microsoft will build Win32-specific things into their .NET client libraries. Or have we already forgotten what they did with Java??
No.
That won't help you when the chips are down. Either you can word the service agreement so that you can absolve yourself of blame in the event of hardware or software failure (in which case the database you're using won't make a bit of difference), or you are going to be in violation of your service agreements no matter whose fault it really is (as long as it's not the customer's). Your customers simply aren't going to care whether it's a problem with Oracle or a problem with you: they're paying you, not Oracle, so if you happen to have a database problem on your end that causes the service agreement to be violated, the customer will blame you, period.
Seems to me that the ability to shift the blame to someone else is only useful to middle managers who are trying to climb the corporate ladder, not real businesses with real, paying customers. Blaming others for problems that are causing pain to your customers only makes you look stupid in the eyes of your customers. All the customer cares about is that you get the problem(s) fixed -- no matter whose "fault" it is.
Yes, but the history of the world is full of evolutionary dead ends. Just because something is an evolutionary dead end doesn't mean it won't happen. Quite the contrary: evoluationary dead ends are the norm. It's the stuff that survives evolution that is unusual, and the only reason we don't think of it that way is that the stuff that has survived evolution is generally what we find in our environment.
No, a disease that can wipe out the species is very possible, and is something that should be factored into the Drake equation.
If this is the case, why does going to a smaller process (0.13u versus 0.18u, for instance) yield such a large drop in power consumption by the same chip design running at the same clock speed?
Intel Guy: Yeah, Yamhill. Stands for "Yet Another Molehill" ... as in what your processor is.
I can understand that X fonts originally were simple bitmaps that got rendered directly to the screen. But the X server knows what kind of visual is being rendered to, so I don't see why it can't render in a more sophisticated manner when drawing to a visual with at least 16 bits worth of color depth.
Were the original designers of the font rendering mechanism so braindead as to specify that all fonts forevermore would be bitmaps??? What the hell for???
As for the X font protocol, that's easy: design an upgraded protocol that the X server can also deal with, that's used to transmit font information along with transparency information. Or use a separate channel for the transparency information and keep the bitmap protocol the way it is.
But either way, font rendering belongs in the server, and having the client do it is complete nonsense.
I mean, the GC is an opaque data type, as is the Font, right? So what's to prevent you from having a mask with a depth greater than 1, which is created when you use XSetFont() with a font that has alpha information?
Help! I don't understand!!
Would it be easier to write the game for Linux and then do the port to Windows? Which is more difficult, going from Windows to Linux or from Linux to Windows? I'd imagine Linux -> Windows is easier to do since you'll be using a set of libraries that are more likely to be cross-platform than if you started with Windows.
But that's just my guess.
I was hoping someone would finally come up with a good method to use in lunzip (see this for more details. In short, it's a superior compression utility, at least for certain jobs, like prepping your computer for the FBI).
Yeah, and we've all seen for ourselves all of the nasty, horrible things that happen to Microsoft as a result of anti-trust action. Like ... er ... umm ... well, I'm sure there's been something!
The article says that SGI has "transferred" the patents to Microsoft. This implies that SGI sold Microsoft the patents themselves, not merely a license to use them.
XML to the rescue!
I mean, XML is the solution to all our problems, right?
</SARCASM>
Ah, cool. Ports allows you to determine what piece of software a file belongs to and things like that? If so, then it sounds like a nice solution.
Very good. So what do you do if you want to install binary-only packages that don't have corresponding source (VMWare comes to mind as one such package, though it might not be ported to FreeBSD)?
Ah. I see. You just install it and track it manually.
Well, as a system administrator, that's not good enough for me. The reason I like to use a package management system is that it makes it EASY to manage the huge number of files on my system. If I'm not sure what bit of software a particular file belongs to, I can query the package manager (not every file has a manpage, you know). Can you do that with ports?
Ports is an awesome way to keep your system up to date, but don't confuse it with a good package manager. They serve different needs.