Re:Milestone target: Running .NET over Wine
on
Fun With Wine
·
· Score: 2
The.NET CLR runs on top of the Win32 API and is not a replacement. Therefore, in theory, a fully working WINE will allow.NET to run straight on top of WINE.
Do you think that the.NET license will allow that? If not, then you have to duplicate all of.NET in order to support.NET applications. In other words there is a whole new API that over time will make WINE obsolete. On the other hand, the Windows API was invented years before the WINE project started whereas Mono is only months behind.NET. So it is at least conceivable that there will be a complete open source.NET clone before there are even many popular programs that depend upon.NET.
SVG is a vector graphics standards with dynamic DOM style elements intended to work in concert with other W3C web standards. It isn't intended to be a super, all-encompassing multimedia solution, as Flash strives for.
SVG works in concert with a language called "Simple Multimedia Integration Languge" which does allow the integration of various media types into an "all-encompassing multimedia solution." When you combine the stack of W3C standards and extrapolate it does look to me like the set is on target to replace Flash.
SVG isn't going to replace Flash anymore than Flash is going to replace binary games (i.e. We're not going to play Doom 3 as a Flash game): Each has its place.
There's been a trend away from non-leaky abstractions. LISP, for example, was by design a non-leaky abstraction; you don't need to know how it works underneath.
Right, and there is a huge trend towards Lisp development in the last few years.
Leaky abstractions will always be with us. Yes, as time goes by we patch some of the egregious leaks (probably a big part of why Java is more popular than C++) but then we just build new leaky abstractions on top (e.g. Jython).
By the way, I would be surprised if Lisp float programming was significantly less leaky than that in other languages.
It took four years to decode ONE document and this isn't even using standard key-length sizes. What do you mean by "relatively insecure". Relative to what?
SAML is not part of XML and in no way complicates XML. SAML is a specification built on XML. But to say that SAML complicates XML would be like saying that Mozilla complicates glib.
As long as you don't get a DTD with extensive comments on how to interpret the elements, along with some promise/guarantee that the DTD won't change every minor release, there is no real improvement at all.
Have you ever tried to reverse engineer a binary file format? And have you ever tried to do the same thing with an XML file format? I learned huge chunks SVG yesterday _without_ opening an SVG book, just by mucking around in an existing SVG file and with an SVG viewer. Of course, Microsoft could do something clearly in violation of the spirit of XML, by making the whole thing one tag full of base64ed text or something. But as long as they use tags in a semi-sane way (which is the whole point, for integration with corporate systems), XML will be a big step forward.
Can you make the case that XML 1.1 is a sufficient "improvement" to require millions of people to upgrade their browsers, and other XML-consuming applications? Do you really think anyone cares about NEL or Mongolian tag names that much?
Just FYI, I don't really care much about this issue. XML 1.1 will cause someone out there pain but probably not me. I just wanted to see both sides of the argument represented.
Where did you get the idea that the software is broken?
The software is broken because it purports to generate XML but does not conform to the XML standard. Or perhaps it is a human being generating the XML. In which case, they should run the equivalent of "dos2unix": "mainframe2XML" and they'll have XML they can share with everyone else.
Essentially 'just fix the software' involves operating system-level changes as well as possibly changes to most software that interprets NEL characters on that OS.
That is certainly not true. Producing XML is always a process undertaken by either a human being (creating it by hand) or a computer (generating it). In the former case, one can change NELs to \n's with the mainframe equivalent of sed. You could build this into the text editor or make it a one-line postprocess. In the latter case, you ALREADY have to do all kinds of character escaping and transcoding to get your data into XML in the first place. Do it there. You certainly don't have to change the OS kernel.
I think everyone agrees that the XML standards should be backwards-compatible, but you seem to be asserting the idea that it should be FORWARD-compatible and that a parser written today must correctly handle all future revisions that might ever be made, which is ludicrous.
No, I'm not saying that parsers should be forwards-compatible. I'm saying that there is very little call by any actual users for a new version of XML with these features. I'll defer to Rusty for details.
And what will an XML 1.0 parser ("millions served") do with an XML 1.1 document? When your IBM mainframe serves up 1.1 data with NEL to my Windows 98 with IE 5.5, IE will complain that the document is not well-formed. This means that there is a period of time where the XML world is split. It will be a LONG time before these mainframe users will be able to use NEL and confidently send the data to anyone else. It might have been cheaper to just fix the software.
Considering what some other vendors have done to standards, one tiny addition (which is an improvement) proposed by IBM shouldn't be a big deal.
Two wrongs make a right?
IBM has contributed so much, it's only natural that some changes might be characterized in the news as benefitting them more than other parties.
I don't know what that means. This change was requested by IBM and only IBM. As far as I know, no IBM customers have even stood up and asked for it publically (I could be wrong).
Is anyone that worried about adding a new EOL character in 1.1 that XML 1.0 "chokes" on ?
Obviously some people are.
Let's keep in mind that there are millions of XML parsers out there and they work together in large part
because there is only one version of XML. Now there are
two and it will take years to roll out the new
parsers universally.
There are all kinds of funny characters that XML does not support. You can't use zero-width or non-breakingspaces as whitespace either. You can't use circled numerals as numbers. etc. NEL is only special because IBM is a big enough company to get attention paid to its legacy software. "Legacy software" and "unicode" seem like an odd mix to me anyhow. Couldn't NEL problems be fixed in a transcoder?
The Slashdot commentary has been pretty one-sided so I'll try and address the other side. First, IBM has said that this fix is for their mainframe customers, not for themselves. But nobody in the XML world has heard from these customers. As far as I know, no user has submitted a request for this NEL feature. No user has sent a message to the many XML mailing lists. No user has posted to Slashdot. Updating all of the XML parsers in the world is really expensive and if the mainframers don't care enough about the problem to storm the gates then maybe it isn't hurting them that badly. So from a democratic point of view, we're going to make life harder for the people who care enough to scream out loud in order to make life easier for the small minority who perhaps are not even that badly impacted.
What I said was that for a given URL, which may very well be http://someplace.com/, how can you tell if it was IP end to end? You can't.
My browser makes an IP connection to "someplace.com". If it is gatewayed that's not an issue I care about. But that AppleTalk server can never serve data without the cooperation of that gateway. If they want to run an SMTP server, they are hosed. If they want to run a Jabber server, they are hosed. Disallowing people inside the firewall may be a perfectly good security policy but it doesn't make sense to deploy that security policy by merely neglecting to deploy IP. When you decide you want to loosen that security policy your hands will be tied.
If you keep explicit IP addresses out of URLs, then you can have hostname based virtual web hosting, mail domains, and so on.
If the IP address was in someplace.com it wouldn't stop the machine from gatewaying for some AppleTalk box. Apache does the gatwaying. It is as happy to gateway for an IP address as for a "host:" headers.
The point is that by keeping the network address out of the URL, you can be more flexible in what the URL resolves to. Maybe it resolves to IPv6, or maybe it resolves to IPv4, depending on what your system supports -- that is a superior solution, isn't it?
Look, hardly anyone goes around exposing URLs with IP addresses in them so you are attacking a straw man. The question is whether devices should be directly IP addressable or hidden behind NATs and proprietary protocols. The question has been answered by the market. People prefer to have DNS/IP addresses when they can get them and once IPv6 increases the number of them, people will ask for them and get them. And yes, that includes people's handheld computers and eventually cell phones. In particular any device that can run arbitrary code like a handheld computer should have an IP address so that it can run new IP-based protocols as they are invented.
Successful application protocols do not define their own address spaces from scratch. They always build on IP/DNS. This isn't poor engineering. It's separation of concerns.
You say:
Maybe a URL points directly to a machine on the Internet with a static IP address. Maybe it points to a machine behind a firewall with NAT. Maybe it points to an IPX machine on the otherside of a protocol coverter. If you can get the files via that URL, it shouldn't matter, should it?
Now I share the URL with someone on the other side of the planet in another administrative domain. Can I guarantee that they can access the resource? If and only if they speak the same protocol or have access to a gateway (which is from my point of view the same thing as speaking the protocol). What protocol do they have a 95% chance of speaking? IP. What other protocol comes close?
Sure, my application could support some other protocol, but then I have to convince the application developer on the other side to support that protocol also. For file transfer applications that's essentially impossible.
Here's a URL that doesn't use IP. It works great on my machine. I hope it is similarly useful to you!
Now if IP is totally unsuited for the application then we shouldn't use it for the actual conversation. But IP can certainly be the bootstrap that we used to negotiate a better protocol. If we can't negotiate that better protocol at least we can communicate why so the end-users know what is going on.
If your application consists primarily of transferring files without stringent latency issues, IP is fine and in fact HTTP is usually fine. Most devices have a need to transfer files, whether they are address books, musical ringers,
or other configuration files. Can we agree that IP is the best solution by virtue of its ubiquity and simplicity?
Once IP is so-deployed, it also makes sense to use it as a boostrap into other protocols -- if you can handle the latency of the negotiation. IP (whether v4 or v6) is the protocol least likely to go away so using it as a boostrap frees your hand to experiment more easily with other kinds of protocols (e.g. streaming sound and video protocols which are always changing).
Both of these argue that IP really should be deployed everywhere. Anyhow, it is hardly worth arguing about. Before 1990 we lived in the world where there were dozens of competing protocols and applications had to explicitly bridge them. That world went away for a reason and it isn't coming back no matter what we conclude on Slashdot.
he "everything over IP" crowd seems to be mostly the same group that feels that NAT is a bad thing -- i.e. that everything should be one big network with the same addressed space (i.e. the Intranet, really, rather than the Internet, because the latter implies connections between different networks.)
Nobody disputes the value of having different networks connected together. But what makes the Internet the dominant network on the planet is that it connected those networks into a single address space. The reason you want this can be summarized as Metcalfe's law. The benefits are eminently practical. For instance, if you have a machine in the Internet address space and you want to make files available to me, you just tell me the IP number of your machine and I can connect and use FTP or WebDAV to get the files. But if you give me an AppleTalk, SMB or Intranet address, I probably cannot connect to you. This isn't utopian idealism, it is pragmatic engineering.
Now the truth is that I really don't care much whether every two machines in the world choose to talk IP to each other. On a network of Macintoshes, use Appletalk. On a network of cell phones, use whatever protocol they use. But I do want every machine int he world to have a unique IP address so that it can participate directly in Internet protocols like HTTP, SMTP, Jabber and SIP. Supporting IP+X is even better than IP alone, if X adds value to IP.
2) True photographic artists will make you look great, and they don't sell negatives...
The point is that in the future they will probably sell you the "digtal negatives" because customers will want the digital form more than the wedding album so that they can share their pictures with people who live far away.
The author posits that fifty years from now there will be a drastic reduction in the number of photographers per town because digital cameras will democratize picture taking so much. I think that he is deeply confused about what photographers do. Photographers do things like lighting, composition and framing that have nothing to do with the particular technology available. Sure, in the future photographers will charge for their services rather than for physical prints. But that will only emphasize the specialized nature of those services. Perhaps wedding photographers will be squeezed by those who think that Uncle Bill can do it but there are many sub-specialties of photography. Even in the world of wedding photographers there is an even chance that people will continue to prefer professional composition and lighting to "taking your chances" with whatever the guests take.
Portrait artists didn't go out of business. The business evolved into photographic portraiture. Now the analog business will evolve into the digital one. The skill of capturing the moment will not be dispersed any better through the evolution of technology.
Why isn't there a link to the ARTICLE?
on
Mr Anti-Google
·
· Score: 2, Redundant
Thanks, I already know how to get to Google and Salon. What I don't know is how to find the Salon article, especially after it scrolls off of Salon's front page.
Slashdot Mirror
The .NET CLR runs on top of the Win32 API and is not a replacement. Therefore, in theory, a fully working WINE will allow .NET to run straight on top of WINE.
Do you think that the .NET license will allow that? If not, then you have to duplicate all of .NET in order to support .NET applications. In other words there is a whole new API that over time will make WINE obsolete. On the other hand, the Windows API was invented years before the WINE project started whereas Mono is only months behind .NET. So it is at least conceivable that there will be a complete open source .NET clone before there are even many popular programs that depend upon .NET.
SVG is a vector graphics standards with dynamic DOM style elements intended to work in concert with other W3C web standards. It isn't intended to be a super, all-encompassing multimedia solution, as Flash strives for.
SVG works in concert with a language called "Simple Multimedia Integration Languge" which does allow the integration of various media types into an "all-encompassing multimedia solution." When you combine the stack of W3C standards and extrapolate it does look to me like the set is on target to replace Flash.
SVG isn't going to replace Flash anymore than Flash is going to replace binary games (i.e. We're not going to play Doom 3 as a Flash game): Each has its place.
What's Flash's natural place? Why couldn't SVG evolve to replace it?
There's been a trend away from non-leaky abstractions. LISP, for example, was by design a non-leaky abstraction; you don't need to know how it works underneath.
Right, and there is a huge trend towards Lisp development in the last few years.
Leaky abstractions will always be with us. Yes, as time goes by we patch some of the egregious leaks (probably a big part of why Java is more popular than C++) but then we just build new leaky abstractions on top (e.g. Jython).
By the way, I would be surprised if Lisp float programming was significantly less leaky than that in other languages.
It took four years to decode ONE document and this isn't even using standard key-length sizes. What do you mean by "relatively insecure". Relative to what?
SAML is not part of XML and in no way complicates XML. SAML is a specification built on XML. But to say that SAML complicates XML would be like saying that Mozilla complicates glib.
As long as you don't get a DTD with extensive comments on how to interpret the elements, along with some promise/guarantee that the DTD won't change every minor release, there is no real improvement at all.
Have you ever tried to reverse engineer a binary file format? And have you ever tried to do the same thing with an XML file format? I learned huge chunks SVG yesterday _without_ opening an SVG book, just by mucking around in an existing SVG file and with an SVG viewer. Of course, Microsoft could do something clearly in violation of the spirit of XML, by making the whole thing one tag full of base64ed text or something. But as long as they use tags in a semi-sane way (which is the whole point, for integration with corporate systems), XML will be a big step forward.
Can you make the case that XML 1.1 is a sufficient "improvement" to require millions of people to upgrade their browsers, and other XML-consuming applications? Do you really think anyone cares about NEL or Mongolian tag names that much?
Just FYI, I don't really care much about this issue. XML 1.1 will cause someone out there pain but probably not me. I just wanted to see both sides of the argument represented.
Where did you get the idea that the software is broken?
The software is broken because it purports to generate XML but does not conform to the XML standard. Or perhaps it is a human being generating the XML. In which case, they should run the equivalent of "dos2unix": "mainframe2XML" and they'll have XML they can share with everyone else.
Essentially 'just fix the software' involves operating system-level changes as well as possibly changes to most software that interprets NEL characters on that OS.
That is certainly not true. Producing XML is always a process undertaken by either a human being (creating it by hand) or a computer (generating it). In the former case, one can change NELs to \n's with the mainframe equivalent of sed. You could build this into the text editor or make it a one-line postprocess. In the latter case, you ALREADY have to do all kinds of character escaping and transcoding to get your data into XML in the first place. Do it there. You certainly don't have to change the OS kernel.
I think everyone agrees that the XML standards should be backwards-compatible, but you seem to be asserting the idea that it should be FORWARD-compatible and that a parser written today must correctly handle all future revisions that might ever be made, which is ludicrous.
No, I'm not saying that parsers should be forwards-compatible. I'm saying that there is very little call by any actual users for a new version of XML with these features. I'll defer to Rusty for details.
And what will an XML 1.0 parser ("millions served") do with an XML 1.1 document? When your IBM mainframe serves up 1.1 data with NEL to my Windows 98 with IE 5.5, IE will complain that the document is not well-formed. This means that there is a period of time where the XML world is split. It will be a LONG time before these mainframe users will be able to use NEL and confidently send the data to anyone else. It might have been cheaper to just fix the software.
Considering what some other vendors have done to standards, one tiny addition (which is an improvement) proposed by IBM shouldn't be a big deal.
Two wrongs make a right?
IBM has contributed so much, it's only natural that some changes might be characterized in the news as benefitting them more than other parties.
I don't know what that means. This change was requested by IBM and only IBM. As far as I know, no IBM customers have even stood up and asked for it publically (I could be wrong).
Is anyone that worried about adding a new EOL character in 1.1 that XML 1.0 "chokes" on ?
Obviously some people are. Let's keep in mind that there are millions of XML parsers out there and they work together in large part because there is only one version of XML. Now there are two and it will take years to roll out the new parsers universally.
There are all kinds of funny characters that XML does not support. You can't use zero-width or non-breakingspaces as whitespace either. You can't use circled numerals as numbers. etc. NEL is only special because IBM is a big enough company to get attention paid to its legacy software. "Legacy software" and "unicode" seem like an odd mix to me anyhow. Couldn't NEL problems be fixed in a transcoder?
The Slashdot commentary has been pretty one-sided so I'll try and address the other side. First, IBM has said that this fix is for their mainframe customers, not for themselves. But nobody in the XML world has heard from these customers. As far as I know, no user has submitted a request for this NEL feature. No user has sent a message to the many XML mailing lists. No user has posted to Slashdot. Updating all of the XML parsers in the world is really expensive and if the mainframers don't care enough about the problem to storm the gates then maybe it isn't hurting them that badly. So from a democratic point of view, we're going to make life harder for the people who care enough to scream out loud in order to make life easier for the small minority who perhaps are not even that badly impacted.
Further discussion is on xml.com.
Most files have no detectable fingerprint and this will only become more common as more text-based formats (XML) proliferate.
What better fingerprint do you want than an XML namespace?
Here is another one
What I said was that for a given URL, which may very well be http://someplace.com/, how can you tell if it was IP end to end? You can't.
My browser makes an IP connection to "someplace.com". If it is gatewayed that's not an issue I care about. But that AppleTalk server can never serve data without the cooperation of that gateway. If they want to run an SMTP server, they are hosed. If they want to run a Jabber server, they are hosed. Disallowing people inside the firewall may be a perfectly good security policy but it doesn't make sense to deploy that security policy by merely neglecting to deploy IP. When you decide you want to loosen that security policy your hands will be tied.If you keep explicit IP addresses out of URLs, then you can have hostname based virtual web hosting, mail domains, and so on.
If the IP address was in someplace.com it wouldn't stop the machine from gatewaying for some AppleTalk box. Apache does the gatwaying. It is as happy to gateway for an IP address as for a "host:" headers.
The point is that by keeping the network address out of the URL, you can be more flexible in what the URL resolves to. Maybe it resolves to IPv6, or maybe it resolves to IPv4, depending on what your system supports -- that is a superior solution, isn't it?
Look, hardly anyone goes around exposing URLs with IP addresses in them so you are attacking a straw man. The question is whether devices should be directly IP addressable or hidden behind NATs and proprietary protocols. The question has been answered by the market. People prefer to have DNS/IP addresses when they can get them and once IPv6 increases the number of them, people will ask for them and get them. And yes, that includes people's handheld computers and eventually cell phones. In particular any device that can run arbitrary code like a handheld computer should have an IP address so that it can run new IP-based protocols as they are invented.
Successful application protocols do not define their own address spaces from scratch. They always build on IP/DNS. This isn't poor engineering. It's separation of concerns.
You say:
Maybe a URL points directly to a machine on the Internet with a static IP address. Maybe it points to a machine behind a firewall with NAT. Maybe it points to an IPX machine on the otherside of a protocol coverter. If you can get the files via that URL, it shouldn't matter, should it?
Now I share the URL with someone on the other side of the planet in another administrative domain. Can I guarantee that they can access the resource? If and only if they speak the same protocol or have access to a gateway (which is from my point of view the same thing as speaking the protocol). What protocol do they have a 95% chance of speaking? IP. What other protocol comes close?
Sure, my application could support some other protocol, but then I have to convince the application developer on the other side to support that protocol also. For file transfer applications that's essentially impossible.
Here's a URL that doesn't use IP. It works great on my machine. I hope it is similarly useful to you!
Now if IP is totally unsuited for the application then we shouldn't use it for the actual conversation. But IP can certainly be the bootstrap that we used to negotiate a better protocol. If we can't negotiate that better protocol at least we can communicate why so the end-users know what is going on.
If your application consists primarily of transferring files without stringent latency issues, IP is fine and in fact HTTP is usually fine. Most devices have a need to transfer files, whether they are address books, musical ringers, or other configuration files. Can we agree that IP is the best solution by virtue of its ubiquity and simplicity?
Once IP is so-deployed, it also makes sense to use it as a boostrap into other protocols -- if you can handle the latency of the negotiation. IP (whether v4 or v6) is the protocol least likely to go away so using it as a boostrap frees your hand to experiment more easily with other kinds of protocols (e.g. streaming sound and video protocols which are always changing).
Both of these argue that IP really should be deployed everywhere. Anyhow, it is hardly worth arguing about. Before 1990 we lived in the world where there were dozens of competing protocols and applications had to explicitly bridge them. That world went away for a reason and it isn't coming back no matter what we conclude on Slashdot.
he "everything over IP" crowd seems to be mostly the same group that feels that NAT is a bad thing -- i.e. that everything should be one big network with the same addressed space (i.e. the Intranet, really, rather than the Internet, because the latter implies connections between different networks.)
Nobody disputes the value of having different networks connected together. But what makes the Internet the dominant network on the planet is that it connected those networks into a single address space. The reason you want this can be summarized as Metcalfe's law. The benefits are eminently practical. For instance, if you have a machine in the Internet address space and you want to make files available to me, you just tell me the IP number of your machine and I can connect and use FTP or WebDAV to get the files. But if you give me an AppleTalk, SMB or Intranet address, I probably cannot connect to you. This isn't utopian idealism, it is pragmatic engineering.
Now the truth is that I really don't care much whether every two machines in the world choose to talk IP to each other. On a network of Macintoshes, use Appletalk. On a network of cell phones, use whatever protocol they use. But I do want every machine int he world to have a unique IP address so that it can participate directly in Internet protocols like HTTP, SMTP, Jabber and SIP. Supporting IP+X is even better than IP alone, if X adds value to IP.
webcal links are not a feature, they are a bug to work around another bug.
2) True photographic artists will make you look great, and they don't sell negatives...
The point is that in the future they will probably sell you the "digtal negatives" because customers will want the digital form more than the wedding album so that they can share their pictures with people who live far away.
The author posits that fifty years from now there will be a drastic reduction in the number of photographers per town because digital cameras will democratize picture taking so much. I think that he is deeply confused about what photographers do. Photographers do things like lighting, composition and framing that have nothing to do with the particular technology available. Sure, in the future photographers will charge for their services rather than for physical prints. But that will only emphasize the specialized nature of those services. Perhaps wedding photographers will be squeezed by those who think that Uncle Bill can do it but there are many sub-specialties of photography. Even in the world of wedding photographers there is an even chance that people will continue to prefer professional composition and lighting to "taking your chances" with whatever the guests take.
Portrait artists didn't go out of business. The business evolved into photographic portraiture. Now the analog business will evolve into the digital one. The skill of capturing the moment will not be dispersed any better through the evolution of technology.
Thanks, I already know how to get to Google and Salon. What I don't know is how to find the Salon article, especially after it scrolls off of Salon's front page.