Are you just making things up without having any actual experience of what it's like to work in a corporate environment?
Seven years of it.
As a C++ developer, I work with developers who use other languages (especially VB, which I detest) on a daily basis
Solution: fire them.
and *the* reason for going with.NET on Windows is the language-independent nature of the CLR. It works, and people use it. There's no need to pontificate about whether or not people 'wanted to use objects from different languages', since they do want to do it, and are doing it with.NET.
Again -- if it was necessary, their work was worthles in the first place. Everyone else just uses existing interfaces or simply connects those programs through sockets. If they can't do that, or the effort they have to apply to it is not trivial compared to the rest of their work, they are not qualified to work on a project in the first place.
As for 'only being able to call things', most of us these days use what we call 'object oriented' development techniques. Rather than using data structures that are independent of the executable code, we use 'classes', in which the code and the data are stored in a single instance (the code is shared by the implementation in most cases, but it's conceptually per-instance).
Drop the condescending tone. Object-oriented design in no way replaces the data structures -- it's just some people study OO _instead_ of data structures and never learned what they are for. Or, worse, can only use some primitive templte library and believe this is all they will ever need.
The truth is, if you have a graph represented by your data it's still a graph no matter how poorly it is implemented, and you have to somehow maintain relationships between objects. Inclusion of easier way to call methods does nothing for it.
The interfaces implemented by the class are used to manipulate the data contained in the instance, and conformant.NET interfaces can be called by any.NET language.
As long as the list of arguments is limited, and results of operation are confined to the single instance of the object. Too bad, it's usually not true even for simple trees, leave alone more complex structures.
In other words, your comment is nonsense.
In other words, you are too ignorant to understand the problem.
Remoting a class and accessing it from another process (on the local machine or another machine) is trivial -- it 'just works' (I use it all the time).
If it works, the task was trivial to begin with. Usually what you have to access is not a class but a set of objects, with complex relationships between them.
Maybe you should try to learn more about.NET before carrying on about things you clearly don't understand.
I understand it pretty clear, though the stupidity of its design insults me. You however have no capability of understanding anything beyond a simple little model where it works, and if all software you write falls within this model, your work is worthless.
This is just a troll..NET apps run in a configurable security sandbox, and use runtime type checking. How often does your Java code suffer from a buffer overrun?
I find it disgusting that the only time Microsoft adopts a good idea is when they can make an implementation stuffed with some irrelevant crap to the limit and far beyond.
The job of a shell is to talk to the user, call programs and run scripts. It is not to mess with the network or have giant builtin pieces such as dotnet interface. If they wanted to do something reasonable they could've just distribute bash and a wrapper utility to call whatever they want in dotnet.
I absolutely agree that.NET API is superior to the combination of Win32 and COM. The problem is, Win32 and COM are absolutely horrible APIs that pretty much everything else is superior to.
What I am talking about is not "if it's better than an existing API" but "if it's better than whatever can be made for a specific task by more or less sane programmer without using pre-packaged API". My point is that software development with.NET is at most marginally simplier compared to design and implementation from scratch (that means, no COM or Win32 involved), and the result is usually far inferior compared to "from scratch".
Maybe some "developers" believe that they get some great value from.NET, however all I see is marginal improvement of operation that usually represents a fraction of a percent of the effort necessary for the development of a product. I guess, those "developers" never did any nontrivial software development, and since everything that is trivial and useful is already implemented, those developers make only trivial and useless things, basically wasting oxygen, energy and bandwidth.
One single problem that crosses out everything -- no objects and relationships/references replication. If that was there, it would actually contribute something infrastructure-like, but since it never was meant to even touch things like that, all its "innovation" and "usefulness" will be at the level of "let's make everyone use Segway instead of walking across the office".
I am talking about the impact of API on thr software development, not about its size. It's almost impossible to make large far-reaching thing useful, but it's a poor excuse for making useless large far-reaching things. It's simply not any better with infrastructure than without it, except for a bunch of people who make a specific kind of programs that may benefit from it -- and it's not even clear that those programs are needed in thr first place.
Languages compatibility is a strawman -- no one ever wanted to use objects from different languages unless all interfaces were compatible enough to make serialization of requests trivial, with or without "infrastructure". In any case all.NET does is allowing to call things, it does nothing to support complex data structures across the network, or even between programs.
Uh. If there are undocumented classes (e.g. non public APIs) then they don't need to be implemented because noone uses them. If they're public they need to be documented for people to use them. You can also just call the methods and see the return values with various argument values.
Microsoft software will use them, and other software will use that Microsoft software. Soon there will be a huge chunk of.NET software that won't run on non-Microsoft platform.
Besides, who cares about Microsoft.NET APIs? The CLI is a good framework regardless of whether you use the Microsoft-only namespaces or not. GTK#, CsGL etc don't need to rely on any non-CLI classes.
It's a large and messy framework made with no understandable purpose other than "making another Java", therefore it's mental masturbation squared (because Java design is mental masturbation -- all its original goals are either abandoned or became irrelevant at the moment when semi-usable implementation was released).
The CLI is very much like C + CLIB. You can build proprietry non cross platform libraries on top of it (e.g. Win32) but you can also build open cross platform libaries with it (e.g. OpenGL). Noone is forcing you to use Windows only libraries (e.g. WinForms) when using.NET.
There is no CLIB, it's libc. And win32 has nothing to do with either, it's an API with its own library, and a horrible one at that.
Mono may never be 100% compatible with MS.NET but that doesn't prevent it from being an extremely useful development framework.
It's a horrible framework -- it is very narrow in functionality and very broad in its stretch over all aspects of program's design and behavior -- basically such infrastructures are for software development what are "wizards" for system administration. Examples of good infrastructure are very rare, I can only name two -- Unix unified file descriptors and Berkeley sockets as a decent large-scale infrastructures that actually serve a valid purpose and improved the software design. The only point of bothering to port it somewhere can be to run software developed for it until people will realize how bad it is and rewrite that software in C or C++ with sanely designed libraries. Same applies to Java but at least Java can be made compatible on all platforms.
ISO 8859-1 is "West European". A quick web search seems to indicate it covers about half of the European languages.
And this is who in Europe actually "uses" it.
As a software developer, it pays of in spades because I don't have to answer any questions about languages: if they're in Unicode, they'll always be there.
At the expense of crippling the software.
No more wondering how to get this language to display in that web browser; it just works.
Software is not to "wonder how it will look in a web browser", it's to operate on data. Most of operations can be absolutely byte-value-transparent and they must never depend on charsets and languages in the first place, however ones that are dependent on them usually have to either use tags with metainformation (and there Unicode is not any better than anything else) or do some horrible guesswork -- say, which language is used in a certain chunk of text that contains some characters (what simply should never be done in the first place, but Unicode accomplishes nothing for it because characters are shared between languages). Displaying pretty characters is easy. So easy, one should never think about it. However a computer is not a typewriter, and therefore charsets and encodings should never be designed to simplify a tiny bit the simple task of displaying while turning any complex text processing into a complete hell.
If I want a character, I can look up the bytes; if I know the bytes, I can look up the character.
How can a computer LOOK UP the bytes? There is nothing BUT the bytes in the computer's memory so certainly it can't look them up. You can use "bytes" as an index in a font, or you can pass them to some processing routine.
No more "incompatibilities" than you'd get from bugs in any other library on your system.
There are no bugs in the font renderers already -- this is a non-issue. The problem is entirely in trying to force people to make huge amount of assumptions about the data's content in otherwise byte-value transparent operations, just to accommodate UTF-8 where it should not matter. It's a design issue, not implementation.
Well, you could start by looking at everybody who wrote that software you mention.
People who write that software never use their "internationalization" -- they see it as a "feature" to add in the list of marketing checkboxes.
Then add everybody who has to deal with more than just Ameri^H^H^H^H^HEnglish text on a day-to-day basis.
That will be me -- and I hate Unicode.
Probably took too small a survey, then. People in my lab write them every day. We write mostly in English (sometimes German), and refer to people, locations, and events in a dozen European countries. Using some pre-Unicode technique, like "codepages", would be a nightmare.
Almost all European languages, including English, are in a single iso8859-1 charset -- what happens to coincide with the beginning of Unicode table. People who use iso8859-1 can "switch to Unicode" and continue using just the same thing with longer bytes, getting no benefit whatsoever but pretending to have "internationalized" their software. For everyone else Unicode causes nothing but trouble, waste of resources and incompatibilities.
As for "code pages" this is a DOS/Windows kludge that is a dumb idea in its own way -- everyone else uses _charsets_ and those can be easily displayed in pretty much everything. The only problem is, no one bothered to make a usable (that means, not XML) tagged format that can include information about languages and charsets used in a document. MIME has charset information for parts of the document, and substrings in the header but not substrings in the document, so it isn't really usable either, however can be used as a proof of viability -- most of mail clients have it all implemented, therefore metainformation with charsets can be easily used.
It's not "as if it was iso-8859-1", it's "byte-value transparent handling of data", and it is a good thing to have -- software not directly involved in displaying data (what is pretty much everything in/usr/bin) should not make assumptions about it other than that it's a sequence of bytes. If UTF-8 will be declared "native" charset, it will have to be enforced/handled in every utility, and those utilities will lose the ability to pass anything else -- even binary data. Want dd to handle blocks? No, can't do that, utilities are not allowed to split multibyte sequences! Want wc to count bytes? Same problem, it will count "characters" instead. And so on -- in the end everything that Unix is built on will have to be ruined just because someone wants to enforce a poorly designed enormous charset that can't be used (or written, or remembered, or designed a complete font) by any single person anyway.
I'll rather use fonts of charsets that I use, and thank the underlying layer and utilities for not messing up my data by assuming that everything they handle is a "text" (as opposed to "binary" -- hi, DOS idiocy, long time no see!) and that I love a semi-proprietary monstrosity of a charset (Unicode) in a variable-length nightmare of encoding (UTF-8).
Seriously, I have yet to see a person (other than Martin Duerst who apparently made a career of stuffing Unicode into everything he notices) willingly using Unicode, as opposed to being forced to do that by some software that requires it. The "internationalization" of documents is a strawman -- at this point in history no non-linguistic document contains more than two languages, local charsets handle that perfectly, and linguists went far beyond what Unicode can provide already, so they have to use different formats anyway. If and when true internationalization will be necessary people will need one simple thing -- language/charset tagging. Tagging is also important because it makes those texts "machine-readable" -- programs will know what parts of text they should interpret using rules that apply to different languages and charsets, and pass "as-is" everything that is in the languages they don't know.
XML already allows language attribute in all tags, and if charset attribute will become valid everywhere where the language is valid, problem will go away immediately and without mandatory Unicode adoption everywhere because everyone who can read a language has a font of a charset that is used with it, and everyone who doesn't shouldn't have problem with occasional
"can't display this section of text, ( ) download "klingon fixed" font to make it readable, (x) show as block, do not edit, ( ) display/edit in hex".
Obviously, a console, or any other kind of program can easily be modified to do that if necessary, and there will be no loss for people that, like myself, simply use their native language + ascii charset, and switch to all other charsets using nice xterm font menu.
Rick Belluzzo at different time was a head, and had destroyed Silicon Graphics/SGI and HP. Then he went to Microsoft, did nothing of value but was paid a giant amount of money as a "loan" that was promptly "forgiven", and Rick himself was gently kicked out when the "loan" story became widely publicized.
Both HP and SGI were Microsoft's major indirect competitors -- they were producing large servers along with Sun and IBM, and now neither HP nor SGI have a working servers division, their native architectures are abandoned, their servers are not anymore significant players anywhere. SGI also was a direct competitor to Microsoft in workstation business, now workstations are no longer produced, after a major fiasco with an attempt to produce a Windows-based workstation using SGI technology. Also I am not sure what role Rick Belluzzo played with selling SGI patents and software to Microsoft that is now being used to prevent the development of OpenGL, and leave Microsoft at the controls of pretty much everything 3D.
All this looks like he either was Microsoft's puppet from the very beginning, or that he is clueless moron who can't make a single business decision without being influenced by Microsoft. Since at Microsoft he did precisely nothing, "loan" looks suspiciously like a payoff for this shining example of service that he did for Microsoft while being a trojan horse in other companies.
I have no idea what mentally deficient people can place him into a CEO position anywhere -- and I should better steer away from anything that Quantum will produce under the management of this crook.
It's an infrastructure, and a very closed one -- ideas of its creators are imposed on the design and can not be changed. If successful, it captures not just software, it takes the area in the noosphere and pollutes (or improves) the process of thinking of all developers that go into that area. This is a kind of work that absolutely can not be developed by anything with commercial interest in mind and end up useful -- examples for that are legion -- PL/1 vs. C, STREAMS vs. BSD Sockets, RPC vs. socket-based protocols with protocol-specific parsing, Motif vs. GTK, H.323 vs. SIP, MPEG audio vs. Vorbis, and I hope, SQL will be next to go. In all cases except PL/1 later there was an open or semi-open implementation of bad standard, and it ended up being absolutely useless for any purpose other than to drag bad code into good systems, thus delaying the development of better one.
Making a port of a system based entirely on mental masturbation. Java and.NET were based on mental masturbation, but they served a purpose -- Java to make applications inefficient (so Sun can sell large servers) but easy to develop for inferior developers (so all kinds of crashy crap will be written for it),.NET -- to create a large and convoluted infrastructure that is even more inefficient (so Intel can sell new hardware incompatible with Linux drivers) and is tied to the design of Windows-specific software (so future developers will learn Windows-specific programming techniques and will be incapable of writing Unix software).
But why do we need to spread the monstrosity is beyond me.
Isn't this one of Microsoft's reasons for avoiding free source projects? How is this any more relevant here than with source code? Do you really think they are going to pay much attention?
...however since spam was published as an evidence of harassment, fraud and/or unauthorized use of your resources, copyright can not be enforced without admitting those acts in court. Contrary to the popular belief, there is no Gestapo -- the only person that by law is allowed to decide that you are guilty, is a judge, and everyone that can threaten you with a law can do that because they expect him to be on their side if things will actually go to court. Spammer to do so must admit that he committed act that you accuse him in the first place -- and he will have to do so in court.
You can't learn new system, especially a superior one, by using tools that are from your old system -- even if they are developed recently. To learn Unix you need to study its design, tools and techniques, not use some monstrosity made to support applications made for Windows under Unix. So forget about Mono, Winelib and Java, learn C (plain C, by K&R book), networking (by UNP book), write something, participate in the development of something that you need, and then you will be able to choose what to do next.
Now you have shown your true face -- accusing me in all kinds of sins ("flaming-sword waving anti-corporate, anti-MS, anti-paying-for-software anything") that FUD is made of, and that has absolutely nothing to do with the matter discussed.
Therefore you are either a FUDmeister from Microsoft, or a pawn in its game -- in either case your "customers' problems" can be dismissed as Microsoft propaganda. Shut up.
This is not an answer -- if no one will do it, we likely will all die because we basically have all eggs in one basket. However what is even more important, someone has to do that simply because this is the nature of human society development -- if there will be nothing to explore, we will reduce ourselves to bickering over limited resources and power over each other, thus producing another stretch of Dark Ages.
Slashdot Mirror
Couldn't they make that blob on the map even larger, or make it of even more unnatural shape?
Are you just making things up without having any actual experience of what it's like to work in a corporate environment?
Seven years of it.
As a C++ developer, I work with developers who use other languages (especially VB, which I detest) on a daily basis
Solution: fire them.
and *the* reason for going with .NET on Windows is the language-independent nature of the CLR. It works, and people use it. There's no need to pontificate about whether or not people 'wanted to use objects from different languages', since they do want to do it, and are doing it with .NET.
Again -- if it was necessary, their work was worthles in the first place. Everyone else just uses existing interfaces or simply connects those programs through sockets. If they can't do that, or the effort they have to apply to it is not trivial compared to the rest of their work, they are not qualified to work on a project in the first place.
As for 'only being able to call things', most of us these days use what we call 'object oriented' development techniques. Rather than using data structures that are independent of the executable code, we use 'classes', in which the code and the data are stored in a single instance (the code is shared by the implementation in most cases, but it's conceptually per-instance).
Drop the condescending tone. Object-oriented design in no way replaces the data structures -- it's just some people study OO _instead_ of data structures and never learned what they are for. Or, worse, can only use some primitive templte library and believe this is all they will ever need.
The truth is, if you have a graph represented by your data it's still a graph no matter how poorly it is implemented, and you have to somehow maintain relationships between objects. Inclusion of easier way to call methods does nothing for it.
The interfaces implemented by the class are used to manipulate the data contained in the instance, and conformant .NET interfaces can be called by any .NET language.
As long as the list of arguments is limited, and results of operation are confined to the single instance of the object. Too bad, it's usually not true even for simple trees, leave alone more complex structures.
In other words, your comment is nonsense.
In other words, you are too ignorant to understand the problem.
Remoting a class and accessing it from another process (on the local machine or another machine) is trivial -- it 'just works' (I use it all the time).
If it works, the task was trivial to begin with. Usually what you have to access is not a class but a set of objects, with complex relationships between them.
Maybe you should try to learn more about .NET before carrying on about things you clearly don't understand.
I understand it pretty clear, though the stupidity of its design insults me. You however have no capability of understanding anything beyond a simple little model where it works, and if all software you write falls within this model, your work is worthless.
This is just a troll. .NET apps run in a configurable security sandbox, and use runtime type checking. How often does your Java code suffer from a buffer overrun?
Who checks the checkers?
.I find it disgusting that the only time Microsoft adopts a good idea is when they can make an implementation stuffed with some irrelevant crap to the limit and far beyond.
The job of a shell is to talk to the user, call programs and run scripts. It is not to mess with the network or have giant builtin pieces such as dotnet interface. If they wanted to do something reasonable they could've just distribute bash and a wrapper utility to call whatever they want in dotnet.
I absolutely agree that .NET API is superior to the combination of Win32 and COM. The problem is, Win32 and COM are absolutely horrible APIs that pretty much everything else is superior to.
.NET is at most marginally simplier compared to design and implementation from scratch (that means, no COM or Win32 involved), and the result is usually far inferior compared to "from scratch".
.NET, however all I see is marginal improvement of operation that usually represents a fraction of a percent of the effort necessary for the development of a product. I guess, those "developers" never did any nontrivial software development, and since everything that is trivial and useful is already implemented, those developers make only trivial and useless things, basically wasting oxygen, energy and bandwidth.
What I am talking about is not "if it's better than an existing API" but "if it's better than whatever can be made for a specific task by more or less sane programmer without using pre-packaged API". My point is that software development with
Maybe some "developers" believe that they get some great value from
One single problem that crosses out everything -- no objects and relationships/references replication. If that was there, it would actually contribute something infrastructure-like, but since it never was meant to even touch things like that, all its "innovation" and "usefulness" will be at the level of "let's make everyone use Segway instead of walking across the office".
JVM is bad, too -- but at least it was made earlier when people didn't know better.
I am talking about the impact of API on thr software development, not about its size. It's almost impossible to make large far-reaching thing useful, but it's a poor excuse for making useless large far-reaching things. It's simply not any better with infrastructure than without it, except for a bunch of people who make a specific kind of programs that may benefit from it -- and it's not even clear that those programs are needed in thr first place.
Languages compatibility is a strawman -- no one ever wanted to use objects from different languages unless all interfaces were compatible enough to make serialization of requests trivial, with or without "infrastructure". In any case all .NET does is allowing to call things, it does nothing to support complex data structures across the network, or even between programs.
Uh. If there are undocumented classes (e.g. non public APIs) then they don't need to be implemented because noone uses them. If they're public they need to be documented for people to use them. You can also just call the methods and see the return values with various argument values.
Microsoft software will use them, and other software will use that Microsoft software. Soon there will be a huge chunk of .NET software that won't run on non-Microsoft platform.
Besides, who cares about Microsoft .NET APIs? The CLI is a good framework regardless of whether you use the Microsoft-only namespaces or not. GTK#, CsGL etc don't need to rely on any non-CLI classes.
It's a large and messy framework made with no understandable purpose other than "making another Java", therefore it's mental masturbation squared (because Java design is mental masturbation -- all its original goals are either abandoned or became irrelevant at the moment when semi-usable implementation was released).
The CLI is very much like C + CLIB. You can build proprietry non cross platform libraries on top of it (e.g. Win32) but you can also build open cross platform libaries with it (e.g. OpenGL). Noone is forcing you to use Windows only libraries (e.g. WinForms) when using .NET.
There is no CLIB, it's libc. And win32 has nothing to do with either, it's an API with its own library, and a horrible one at that.
Mono may never be 100% compatible with MS.NET but that doesn't prevent it from being an extremely useful development framework.
It's a horrible framework -- it is very narrow in functionality and very broad in its stretch over all aspects of program's design and behavior -- basically such infrastructures are for software development what are "wizards" for system administration. Examples of good infrastructure are very rare, I can only name two -- Unix unified file descriptors and Berkeley sockets as a decent large-scale infrastructures that actually serve a valid purpose and improved the software design. The only point of bothering to port it somewhere can be to run software developed for it until people will realize how bad it is and rewrite that software in C or C++ with sanely designed libraries. Same applies to Java but at least Java can be made compatible on all platforms.
ISO 8859-1 is "West European". A quick web search seems to indicate it covers about half of the European languages.
And this is who in Europe actually "uses" it.
As a software developer, it pays of in spades because I don't have to answer any questions about languages: if they're in Unicode, they'll always be there.
At the expense of crippling the software.
No more wondering how to get this language to display in that web browser; it just works.
Software is not to "wonder how it will look in a web browser", it's to operate on data. Most of operations can be absolutely byte-value-transparent and they must never depend on charsets and languages in the first place, however ones that are dependent on them usually have to either use tags with metainformation (and there Unicode is not any better than anything else) or do some horrible guesswork -- say, which language is used in a certain chunk of text that contains some characters (what simply should never be done in the first place, but Unicode accomplishes nothing for it because characters are shared between languages). Displaying pretty characters is easy. So easy, one should never think about it. However a computer is not a typewriter, and therefore charsets and encodings should never be designed to simplify a tiny bit the simple task of displaying while turning any complex text processing into a complete hell.
If I want a character, I can look up the bytes; if I know the bytes, I can look up the character.
How can a computer LOOK UP the bytes? There is nothing BUT the bytes in the computer's memory so certainly it can't look them up. You can use "bytes" as an index in a font, or you can pass them to some processing routine.
No more "incompatibilities" than you'd get from bugs in any other library on your system.
There are no bugs in the font renderers already -- this is a non-issue. The problem is entirely in trying to force people to make huge amount of assumptions about the data's content in otherwise byte-value transparent operations, just to accommodate UTF-8 where it should not matter. It's a design issue, not implementation.
Well, you could start by looking at everybody who wrote that software you mention.
People who write that software never use their "internationalization" -- they see it as a "feature" to add in the list of marketing checkboxes.
Then add everybody who has to deal with more than just Ameri^H^H^H^H^HEnglish text on a day-to-day basis.
That will be me -- and I hate Unicode.
Probably took too small a survey, then. People in my lab write them every day. We write mostly in English (sometimes German), and refer to people, locations, and events in a dozen European countries. Using some pre-Unicode technique, like "codepages", would be a nightmare.
Almost all European languages, including English, are in a single iso8859-1 charset -- what happens to coincide with the beginning of Unicode table. People who use iso8859-1 can "switch to Unicode" and continue using just the same thing with longer bytes, getting no benefit whatsoever but pretending to have "internationalized" their software. For everyone else Unicode causes nothing but trouble, waste of resources and incompatibilities.
As for "code pages" this is a DOS/Windows kludge that is a dumb idea in its own way -- everyone else uses _charsets_ and those can be easily displayed in pretty much everything. The only problem is, no one bothered to make a usable (that means, not XML) tagged format that can include information about languages and charsets used in a document. MIME has charset information for parts of the document, and substrings in the header but not substrings in the document, so it isn't really usable either, however can be used as a proof of viability -- most of mail clients have it all implemented, therefore metainformation with charsets can be easily used.
It's not "as if it was iso-8859-1", it's "byte-value transparent handling of data", and it is a good thing to have -- software not directly involved in displaying data (what is pretty much everything in /usr/bin) should not make assumptions about it other than that it's a sequence of bytes. If UTF-8 will be declared "native" charset, it will have to be enforced/handled in every utility, and those utilities will lose the ability to pass anything else -- even binary data. Want dd to handle blocks? No, can't do that, utilities are not allowed to split multibyte sequences! Want wc to count bytes? Same problem, it will count "characters" instead. And so on -- in the end everything that Unix is built on will have to be ruined just because someone wants to enforce a poorly designed enormous charset that can't be used (or written, or remembered, or designed a complete font) by any single person anyway.
I'll rather use fonts of charsets that I use, and thank the underlying layer and utilities for not messing up my data by assuming that everything they handle is a "text" (as opposed to "binary" -- hi, DOS idiocy, long time no see!) and that I love a semi-proprietary monstrosity of a charset (Unicode) in a variable-length nightmare of encoding (UTF-8).
Seriously, I have yet to see a person (other than Martin Duerst who apparently made a career of stuffing Unicode into everything he notices) willingly using Unicode, as opposed to being forced to do that by some software that requires it. The "internationalization" of documents is a strawman -- at this point in history no non-linguistic document contains more than two languages, local charsets handle that perfectly, and linguists went far beyond what Unicode can provide already, so they have to use different formats anyway. If and when true internationalization will be necessary people will need one simple thing -- language/charset tagging. Tagging is also important because it makes those texts "machine-readable" -- programs will know what parts of text they should interpret using rules that apply to different languages and charsets, and pass "as-is" everything that is in the languages they don't know.
XML already allows language attribute in all tags, and if charset attribute will become valid everywhere where the language is valid, problem will go away immediately and without mandatory Unicode adoption everywhere because everyone who can read a language has a font of a charset that is used with it, and everyone who doesn't shouldn't have problem with occasional
"can't display this section of text, ( ) download "klingon fixed" font to make it readable, (x) show as block, do not edit, ( ) display/edit in hex".
Obviously, a console, or any other kind of program can easily be modified to do that if necessary, and there will be no loss for people that, like myself, simply use their native language + ascii charset, and switch to all other charsets using nice xterm font menu.
Rick Belluzzo at different time was a head, and had destroyed Silicon Graphics/SGI and HP. Then he went to Microsoft, did nothing of value but was paid a giant amount of money as a "loan" that was promptly "forgiven", and Rick himself was gently kicked out when the "loan" story became widely publicized.
Both HP and SGI were Microsoft's major indirect competitors -- they were producing large servers along with Sun and IBM, and now neither HP nor SGI have a working servers division, their native architectures are abandoned, their servers are not anymore significant players anywhere. SGI also was a direct competitor to Microsoft in workstation business, now workstations are no longer produced, after a major fiasco with an attempt to produce a Windows-based workstation using SGI technology. Also I am not sure what role Rick Belluzzo played with selling SGI patents and software to Microsoft that is now being used to prevent the development of OpenGL, and leave Microsoft at the controls of pretty much everything 3D.
All this looks like he either was Microsoft's puppet from the very beginning, or that he is clueless moron who can't make a single business decision without being influenced by Microsoft. Since at Microsoft he did precisely nothing, "loan" looks suspiciously like a payoff for this shining example of service that he did for Microsoft while being a trojan horse in other companies.
I have no idea what mentally deficient people can place him into a CEO position anywhere -- and I should better steer away from anything that Quantum will produce under the management of this crook.
It's an infrastructure, and a very closed one -- ideas of its creators are imposed on the design and can not be changed. If successful, it captures not just software, it takes the area in the noosphere and pollutes (or improves) the process of thinking of all developers that go into that area. This is a kind of work that absolutely can not be developed by anything with commercial interest in mind and end up useful -- examples for that are legion -- PL/1 vs. C, STREAMS vs. BSD Sockets, RPC vs. socket-based protocols with protocol-specific parsing, Motif vs. GTK, H.323 vs. SIP, MPEG audio vs. Vorbis, and I hope, SQL will be next to go. In all cases except PL/1 later there was an open or semi-open implementation of bad standard, and it ended up being absolutely useless for any purpose other than to drag bad code into good systems, thus delaying the development of better one.
Making a port of a system based entirely on mental masturbation. Java and .NET were based on mental masturbation, but they served a purpose -- Java to make applications inefficient (so Sun can sell large servers) but easy to develop for inferior developers (so all kinds of crashy crap will be written for it), .NET -- to create a large and convoluted infrastructure that is even more inefficient (so Intel can sell new hardware incompatible with Linux drivers) and is tied to the design of Windows-specific software (so future developers will learn Windows-specific programming techniques and will be incapable of writing Unix software).
But why do we need to spread the monstrosity is beyond me.
They assumed that Microsoft is a software company.
Isn't this one of Microsoft's reasons for avoiding free source projects? How is this any more relevant here than with source code? Do you really think they are going to pay much attention?
Because tvnow provides you a service, dum-bass.
Except I kinda like the .NET ads here on Slashdot. They make me chuckle.
"Get Microsoft behind your business"
I really don't think, I would want to have THAT behind my back ;-).
Still it's not "competing" with 2001 -- actually there are only two things in common between those movies:
1. People are in spaceships.
2. Aliens are weird.
...however since spam was published as an evidence of harassment, fraud and/or unauthorized use of your resources, copyright can not be enforced without admitting those acts in court. Contrary to the popular belief, there is no Gestapo -- the only person that by law is allowed to decide that you are guilty, is a judge, and everyone that can threaten you with a law can do that because they expect him to be on their side if things will actually go to court. Spammer to do so must admit that he committed act that you accuse him in the first place -- and he will have to do so in court.
You can't learn new system, especially a superior one, by using tools that are from your old system -- even if they are developed recently. To learn Unix you need to study its design, tools and techniques, not use some monstrosity made to support applications made for Windows under Unix. So forget about Mono, Winelib and Java, learn C (plain C, by K&R book), networking (by UNP book), write something, participate in the development of something that you need, and then you will be able to choose what to do next.
Now you have shown your true face -- accusing me in all kinds of sins ("flaming-sword waving anti-corporate, anti-MS, anti-paying-for-software anything") that FUD is made of, and that has absolutely nothing to do with the matter discussed.
Therefore you are either a FUDmeister from Microsoft, or a pawn in its game -- in either case your "customers' problems" can be dismissed as Microsoft propaganda. Shut up.
This is not an answer -- if no one will do it, we likely will all die because we basically have all eggs in one basket. However what is even more important, someone has to do that simply because this is the nature of human society development -- if there will be nothing to explore, we will reduce ourselves to bickering over limited resources and power over each other, thus producing another stretch of Dark Ages.