You dont know? It wouldn't have been hard to find out
Re:GUI does not imply !(batchable||scriptable)
on
E-Postage for Linux?
·
· Score: 1
Laziness on the part of the developer. I am a developer - a Windows developer (no apologies - I don't use Linux at home. Flame elsewhere), and I make sure the things I produce are appropriately scriptable.
GUI does not imply !(batchable||scriptable)
on
E-Postage for Linux?
·
· Score: 3, Insightful
...or otherwise unusable through automation. Many widely used, widely emulated GUI applications are usable through a command line or script interface.
C# is a nice language. Better? I am more productive in C#. Better/worse is a religious war.
Your understanding is not correct. CLR applications, including those written in C#, have similiar sandbox restrictions as Java. here is the introductory documentation.
Exactly, and with factual cites to back up your assertion, how did they "[do] it again" with C#? Ignoring your misappropriation of C# as the responsible party in the case of CLR security, I still don't really understand the comment at all.
You see, C# is a language. One might rationally compare it to Java. There are similiarities. The essential point here is that the language is a medium for developers to express an executable program. There is also the CLR, which you might liken to the Java runtime environment, ie the JVM. These entities exist to provide an environment for these programs to run within. Does Java the language have security features? Well, it has security-related APIs. So does C#. Does the JVM has security features? Ahhh, yes it does. So does the CLR.
This has nothing to do with UNIX or Linux or the GPL and everything to do with making SCO's legal struggle look as impressive and valid as possible to the investment community so as to make it profitable for SCO's executive branch to dump their holdings.
My experience is largely in.Net, learning Java from a guy I am simultaneously teaching.Net to. Info like this is much appreciated. I wonder - with the high churn/release cycle of many OSS projects, why don't more use Package?
Web Forms is not a fancy name for servlets. They're classes extending the System.Web.Forms.Page class to define behavior, with a separate file defining UI layout.
C# is not an alias for Java(tm), it's an embraced extension of several proprietary languages that was then ratified as a standard.
The CLR is not a JVM. Maybe you might liken an AppDomain to a single JVM.
Web Services are merely classes invoking one another utilizing a STANDARD based upon XML. And if you don't see/need the utility derrived therin, then that is your concern.
There really isn't much, if anything, one can do in.Net that you could not do in JBuilder, Workshop, or Eclipse, etc. The relevant point to make to much of the/. audience is that the relationship is largely bi-directional.
There are lots of products (yes I know it's down but that's their website) that integrate barcode scanners into PDA equipment. The dual-function-as-laser-pointer feature I have not yet seen.... We (along with many other retail chains I am sure) are building UPC lookup via barcode PDA applications as we speak. They are rather trivial - the hardest part being designing a good UI
In Anvil of Stars, Bear introduces a civilization so advanced that they could manipulate vast ammounts of matter over large distances and convert M objects to A-M. Including people. The human's who were converted to A-M died slowly because their organic chemistry was subtly different. Made for a nasty suprise when the pilots tried to re-dock with their mother ship.
Not that this represents anything based in reality or the laws of physics. Just "prior art" from a respected hard sci-fi writer.
I've been working with it for a couple of years. Yes, betas, release candidates, etc. The question largely becomes, can your design scale to those constraints? I am charged with designing web applications, web services, and server processing services that have extremely high availability requirements and high, variable loads. My experience with.Net has been that it has been up to the task in all cases. But my application is not yours, and neither is my staff. First thing to examine is whether you are using Windows 2003. IIS 6 is VASTLY superior to 5 in terms of both reliability and performance.
currently there isn't a mature messaging server and MSMQ is not appropriate for high load messaging platform. Define high. 100 messages per second from multiple threads? I haven't hit any walls with MSMQ in any way, and we use it in a number of different scenarios.
SOAP is too damn heavy weight to scale well beyond 60 concurrent requests for a single CPU 3ghz system. In general, I would tend to agree, but there are ways to improve that situation somewhat, depending on your application and your data. Have you tried exposing pooled.Net COM+ objects as SOAP endpoints? Windows 2003 can do this.
SQL Server doesn't support C# triggers or a way to embed C# applications within the database And your point is? I guess you could wait for Yukon. In the meantime, write them in SQL.
The through put of SQL Server is still around 200 concurrent requests for a single or dual CPU box. I've read the posts about Transaction Processing Council, but get real, who can afford to spend 6 million on a 64 CPU box? Very few people can. The point of MS' entries to the TPC is to introduce the idea to the database community that MS can play in that space. You are going to have a separate SQL Server from your web servers, right?
the clients we target are small-ish, so they can't spend more than 30-50K on a server. so where does that leave you in terms of scalability But they require 100+ concurrent requests per second?
I've been been running benchmarks with dynamic code that does quite a bit of reflection and the performance doesn't impress me. Me either. You sure don't use reflection for the performance. In any language.
I've also compared the performance of a static ASP/HTML page to webservice page and the throughput goes from 150-200 to about 10-20 on a 2.4-2.6Ghz system Static content is pretty cool from a performance standpoint.
to get good through put with SQL Server you have to use async calls, but what if you have to do sync calls? So, do synchronous calls. Index the data well. use stored procedures. Schema qualify your objects. Keep your queries tight.
From what I've seen the performance isn't great (it's ok) and I don't like the idea of setting up partitions. Sure, you can put mirrored raid on all the DB servers, but that doesn't help me if a partition goes down and the data is no longer available. Even MS doesnt recommend using mirrored RAID for data - you use it for transaction logs. Maybe RAID 10 for data, but thats often overkill. RAID 5 for data, mirrors for Transaction log. You are using separate volumes for data and logs, right? Just because MQQSL is easy to use doesnt mean that any chump can run it in a high performance scenario. I asked a MS SQL Server DBA about real-time replication across multiple servers and his remark was "it doesn't work, don't use it." Ok. Ask a few more. Preferably some with some experience doing it right. And ask about log-shipping.
The I/O functionality consists nearly entirely of static methods that, frankly, don't do a lot for you. You're refering to the System.IO.File class? Yeah, it's kinda lame for IO. Really meant for dealing with the attributes of a file, not the contents. I think you missed the System.IO.FileStream class.
You can get a list of filenames in a directory, but I haven't found anything that will parse the filename into path segments and reformat it for various platforms. The System.IO.Path class.
But what I miss most is that in Java, when you call read( byte[] a ) it will read a.length bytes and advance the file pointer so you can perform the same call in a loop until the returned value is less than a.length. In.NET read( byte[] a, int b, int c ) only reads c - b bytes and does *not* advance the pointer. According to the documentation for System.IO.FileStream.Read(), the stream position is indeed updated after each read. You can even use a StreamReader or a BinaryReader to do more complicated/interesting things.
Interestingly, b and c are ints, whereas the file length can be long, so conceivably you could be unable to read the end of a very long file (that is, if there is a distinction between int and long in.NET [BB There is ]). The only way to read in a file in a loop is byte-by-byte (read( ) advances the pointer just fine), which is *very* inefficient. I ran into that while trying to copy an HttpPostedFile into a blob field on a data object. Pain in the ass. I'm sorry you had it rough, but you dont appear to understand how the streams or readers work. As far as large files go, you CAN reach the end if the stream position is updated, which it is.
With respect to I/O, it looks like.NET gives you little more than what you get with a standard C++. I guess I'm just spoiled by Java, which has an extremely robust I/O package.
Might I suggest reading up a little more on the IO capabilities in the.Net framework at MSDN
I'm very sincerely curious about how the IO classes, the date handling and the string formatting are lackluster for you. I do quite a bit with the above and don't really notice a failing in those areas. Also, I'm pretty happy with the documentation.
Now, about your comments WRT Datasets and enterprise dev - I think you're spot on.
We do a lot of development with WebSphere and.Net, and in general, we're finding.Net very productive for Windows development, both client and server side.
Slashdot Mirror
So, /. has done 3 stories on ternary logic?
And I thought it was a technology to help me LEARN perfect pitch.
You dont know? It wouldn't have been hard to find out
Laziness on the part of the developer. I am a developer - a Windows developer (no apologies - I don't use Linux at home. Flame elsewhere), and I make sure the things I produce are appropriately scriptable.
...or otherwise unusable through automation. Many widely used, widely emulated GUI applications are usable through a command line or script interface.
And you read this information where?
C# is a nice language. Better? I am more productive in C#. Better/worse is a religious war.
Your understanding is not correct. CLR applications, including those written in C#, have similiar sandbox restrictions as Java. here is the introductory documentation.
Exactly, and with factual cites to back up your assertion, how did they "[do] it again" with C#? Ignoring your misappropriation of C# as the responsible party in the case of CLR security, I still don't really understand the comment at all.
You see, C# is a language. One might rationally compare it to Java. There are similiarities. The essential point here is that the language is a medium for developers to express an executable program. There is also the CLR, which you might liken to the Java runtime environment, ie the JVM. These entities exist to provide an environment for these programs to run within. Does Java the language have security features? Well, it has security-related APIs. So does C#. Does the JVM has security features? Ahhh, yes it does. So does the CLR.
Is it flamebait if it's true? (See Paragraph 2)
Naaah. You are thinking of the warning that comes with Java(tm)
This has nothing to do with UNIX or Linux or the GPL and everything to do with making SCO's legal struggle look as impressive and valid as possible to the investment community so as to make it profitable for SCO's executive branch to dump their holdings.
You cite a marginally valid point, but lose all credibility with that ad hominem attack on the grandparent.
Actually, the "heighth" of journalistic integrity might begin by getting rid of that literary lisp.
Nope. It's a feature!
Thank you. I actually did go and read it.
.Net, learning Java from a guy I am simultaneously teaching .Net to. Info like this is much appreciated. I wonder - with the high churn/release cycle of many OSS projects, why don't more use Package?
My experience is largely in
Web Forms is not a fancy name for servlets. They're classes extending the System.Web.Forms.Page class to define behavior, with a separate file defining UI layout.
C# is not an alias for Java(tm), it's an embraced extension of several proprietary languages that was then ratified as a standard.
The CLR is not a JVM. Maybe you might liken an AppDomain to a single JVM.
Web Services are merely classes invoking one another utilizing a STANDARD based upon XML. And if you don't see/need the utility derrived therin, then that is your concern.
And how exactly did Java(tm) address versioning?
There really isn't much, if anything, one can do in .Net that you could not do in JBuilder, Workshop, or Eclipse, etc. The relevant point to make to much of the /. audience is that the relationship is largely bi-directional.
There are lots of products (yes I know it's down but that's their website) that integrate barcode scanners into PDA equipment. The dual-function-as-laser-pointer feature I have not yet seen....
We (along with many other retail chains I am sure) are building UPC lookup via barcode PDA applications as we speak. They are rather trivial - the hardest part being designing a good UI
In Anvil of Stars, Bear introduces a civilization so advanced that they could manipulate vast ammounts of matter over large distances and convert M objects to A-M. Including people. The human's who were converted to A-M died slowly because their organic chemistry was subtly different. Made for a nasty suprise when the pilots tried to re-dock with their mother ship.
Not that this represents anything based in reality or the laws of physics. Just "prior art" from a respected hard sci-fi writer.
I've been working with it for a couple of years. Yes, betas, release candidates, etc. The question largely becomes, can your design scale to those constraints? I am charged with designing web applications, web services, and server processing services that have extremely high availability requirements and high, variable loads. My experience with .Net has been that it has been up to the task in all cases. But my application is not yours, and neither is my staff. First thing to examine is whether you are using Windows 2003. IIS 6 is VASTLY superior to 5 in terms of both reliability and performance.
.Net COM+ objects as SOAP endpoints? Windows 2003 can do this.
currently there isn't a mature messaging server and MSMQ is not appropriate for high load messaging platform.
Define high. 100 messages per second from multiple threads? I haven't hit any walls with MSMQ in any way, and we use it in a number of different scenarios.
SOAP is too damn heavy weight to scale well beyond 60 concurrent requests for a single CPU 3ghz system.
In general, I would tend to agree, but there are ways to improve that situation somewhat, depending on your application and your data. Have you tried exposing pooled
SQL Server doesn't support C# triggers or a way to embed C# applications within the database
And your point is? I guess you could wait for Yukon. In the meantime, write them in SQL.
The through put of SQL Server is still around 200 concurrent requests for a single or dual CPU box. I've read the posts about Transaction Processing Council, but get real, who can afford to spend 6 million on a 64 CPU box?
Very few people can. The point of MS' entries to the TPC is to introduce the idea to the database community that MS can play in that space. You are going to have a separate SQL Server from your web servers, right?
the clients we target are small-ish, so they can't spend more than 30-50K on a server. so where does that leave you in terms of scalability
But they require 100+ concurrent requests per second?
I've been been running benchmarks with dynamic code that does quite a bit of reflection and the performance doesn't impress me.
Me either. You sure don't use reflection for the performance. In any language.
I've also compared the performance of a static ASP/HTML page to webservice page and the throughput goes from 150-200 to about 10-20 on a 2.4-2.6Ghz system
Static content is pretty cool from a performance standpoint.
to get good through put with SQL Server you have to use async calls, but what if you have to do sync calls?
So, do synchronous calls. Index the data well. use stored procedures. Schema qualify your objects. Keep your queries tight.
From what I've seen the performance isn't great (it's ok) and I don't like the idea of setting up partitions. Sure, you can put mirrored raid on all the DB servers, but that doesn't help me if a partition goes down and the data is no longer available.
Even MS doesnt recommend using mirrored RAID for data - you use it for transaction logs. Maybe RAID 10 for data, but thats often overkill. RAID 5 for data, mirrors for Transaction log. You are using separate volumes for data and logs, right? Just because MQQSL is easy to use doesnt mean that any chump can run it in a high performance scenario.
I asked a MS SQL Server DBA about real-time replication across multiple servers and his remark was "it doesn't work, don't use it."
Ok. Ask a few more. Preferably some with some experience doing it right. And ask about log-shipping.
The I/O functionality consists nearly entirely of static methods that, frankly, don't do a lot for you.
.NET read( byte[] a, int b, int c ) only reads c - b bytes and does *not* advance the pointer.
.NET [BB There is ]). The only way to read in a file in a loop is byte-by-byte (read( ) advances the pointer just fine), which is *very* inefficient. I ran into that while trying to copy an HttpPostedFile into a blob field on a data object. Pain in the ass.
.NET gives you little more than what you get with a standard C++. I guess I'm just spoiled by Java, which has an extremely robust I/O package.
.Net framework at MSDN
You're refering to the System.IO.File class? Yeah, it's kinda lame for IO. Really meant for dealing with the attributes of a file, not the contents. I think you missed the System.IO.FileStream class.
You can get a list of filenames in a directory, but I haven't found anything that will parse the filename into path segments and reformat it for various platforms.
The System.IO.Path class.
But what I miss most is that in Java, when you call read( byte[] a ) it will read a.length bytes and advance the file pointer so you can perform the same call in a loop until the returned value is less than a.length. In
According to the documentation for System.IO.FileStream.Read(), the stream position is indeed updated after each read. You can even use a StreamReader or a BinaryReader to do more complicated/interesting things.
Interestingly, b and c are ints, whereas the file length can be long, so conceivably you could be unable to read the end of a very long file (that is, if there is a distinction between int and long in
I'm sorry you had it rough, but you dont appear to understand how the streams or readers work. As far as large files go, you CAN reach the end if the stream position is updated, which it is.
With respect to I/O, it looks like
Might I suggest reading up a little more on the IO capabilities in the
I'm very sincerely curious about how the IO classes, the date handling and the string formatting are lackluster for you. I do quite a bit with the above and don't really notice a failing in those areas.
.Net, and in general, we're finding .Net very productive for Windows development, both client and server side.
Also, I'm pretty happy with the documentation.
Now, about your comments WRT Datasets and enterprise dev - I think you're spot on.
We do a lot of development with WebSphere and
So do tell, how has the tweety fone held up?
Its an electrochemical reaction with platinum as a catalyst. Yields water vapor and electricity, and, uhh, some oxide of carbon. Yeah.
NTFS supports reparse points. No UNIX required.