The conservatives are concentrating on fixing things for the kids while the liberals are concentrating on fixing the system.
If you pull the kids out of dangerous, broken schools and put them into better ones, the kids start getting a better education immediately.
I can't disagree with that, but it's only a short-term win. I think you need to look at the long-term too. Yanking everyone out of the public school system will distroy it.
It wouldn't need fixing at all if "intelligent liberals" hadn't broken it to begin with.
As most conservatives are quick to point out, the K-12 education system is under local, not federal, control. So it's hard to see how you can blame the breakage on the federal DoE.
The conservatives in the US are horrified at the k-12 educational system.
So are the (intelligent) liberals. The difference is that the conservatives want to give up on public education (via vouchers) while the liberals want to fix it.
Don't confuse the.NET marketing blitz with the.NET framework. It's probably true that some of the back office products are getting gratiutiously slapped with the.NET moniker (Exchange.NET, anyone?).
On the other hand, the.NET framework and tools (e.g. the Common Language Specification [CLS] and Common Language Runtime [CLR], Assemblies, etc.) are a completely real and completely new platform. Microsoft is turning their ship around on a dime again and anyone with an ounce of objectivity has got to be impressed (even if you prefer writing Java or C++ or ksh93 scripts in the end).
I was weaned on Unix systems many years ago and have been assimilated into the Windows world since. Reading this definitely makes me nostalgic for the well-defined old days. One good thing I can say for Windows, however, is that it is finally taking Korn's advice to allow via scripting (e.g. the Windows Scripting Host) most things that can be accomplished via the GUI.
The Skittles game described above is a zero-sum game: Some number of Skittles come into the room (with the teacher) and the same number of Skittles leave the room (with the teacher and the kids). Note that the teacher is part of the game.
In the above example, the kids were NOT competeing for the skittles
Of course they are. They're just not competing against each other for Skittles.
A skittle for you does not come out of the mouth of another student, it comes from the "banker" of the game.
Exactly. And that's who the kids are competing against. The fact that they have to cooperate with each other in order to obtain Skittles is just an indirect outcome of the competition with the banker.
The point is that even the most selfish (but intellegint) jerk will cooperate with his "opponent" in order to get Skittles. The person who wrote the message I was responding to completely missed this point.
Amazing, you missed the point completely. I'd love to play some poker with you.
The teacher's lesson is not about cooperation instead of competing. It's about competing, and realizing what you are competing for.
So what are these kids competing for? In your mind, they are competing for some sort of abstract "victory" points. But anyone with a brain will eventually realize that victories have no intrinsic value. Pay attention now: The only thing worth accumulating in this game is SKITTLES.
The kids who cooperated got the most Skittles -- more Skittles even than the kids who won every turn. Repeat this to yourself until it sets in.
Your analogy to poker is perfect, and yet you still missed the point. When you play poker are you a) trying to win the most hands?, or b) trying to win the most money? Hint: $$$.
It's mathematically impossible for the dual-proc compile to be "142% faster" than the single-proc compile. Anything more than 100% faster indicates that it takes less than no time.
For example:
Single-proc compile: 100 seconds
Dual-proc compile: 25 seconds
In this case, the dual-proc compile is 75% faster than the single-proc compile. Conversely, the single-proc compile is 300% (4x-1x) slower than the multi-proc compile.
The math for the first calculation is: (1x - (1/4)x) = 75%
Flip this around and you get the math for the second calculation: (4x - 1x) = 300%
I know this is counter-intuitive for some people, but that's how percents work in the real world. Don't blame me.
The OS currently provides consistency, but that doesn't mean consistency has to disappear with the OS crutch gone. Developers just have to get organized.
Okay. And after these hypothetical developers "get organized" around a consistent UI, what would happen next?
Well, of course they would then agree on a common implementation toolkit for the UI (in order to save work, promote reusability, etc.).
What next? They would then have the bright idea of shipping the implementation toolkit with every copy of the computer (in order to make life easier for the customer).
And what do they have then? Why, it's an operating system!
Hear, hear! Folks, if you write C++, learn the STL (which is now part of the language itself).
Unfortunately, in practice most C++ developers write code that is nearly indistinguishable from C. Hence the never-ending stream of new buffer overflow exploits.
-- Brian
Re:Accidents, far more than firearms
on
Clever Girl Bess
·
· Score: 1
Blaming the tool for the person using it's criminal intent is not the answer.
Criminy, no one is blaming the tool. We blame the criminals and thus seek to prevent them from using the tool to commit crimes in the future.
Aside from being unconstitutional (in the US), this seems like a perfectly reasonable plan. Why is it so hard for you to understand?
Interesting point. I thought many firewalls already inspected HTTP headers for this sort of stuff, but I guess not. Have to admit that I'm not a firewall expert. I can tell you for sure that SOAPAction was designed with this intent in mind.
At least SOAPAction is case-sensitive, so you don't have to worry about that.<grin>
1)CORBA object can be made stateless too, you know. It's up to a system designer. Inability to use state actually is a big disadvantage in some systems as performance suffers and implementation gets complicated. CORBA gives you a choice. SOAP doesn't.
You can implement a stateful architecture on top of SOAP, it just doesn't force you to. I guess it's just a question of whether it's easier to add state to SOAP or remove state from CORBA. You may be right about CORBA in theory, but in practice SOAP is so simple that its rapid adoption will simply render the question moot.
2)With SOAP you need at least a full blown web server and XML-DOM parser. ORB-runtime usually is just a shared library.
Okay, but in a few years, every friggin' toaster sold by Target will have a "full blown" web server and an XML parser. Just about every server on the Internet today is already listening for HTTP on Port 80. What's the big deal?
3)IIOP can be tunneled through HTTP as easily as anything else. There are plenty of IIOP/HTTP gateways. Why reinvent the wheel when this is so easy?
Okay, but then where are all the CORBA web services on today's Internet? For one reason or another, people are not doing this. You tell me why.
XML is hugely more expensive to parse than even multipart/form-data, much less application/x-www-form-urlencoded.
Even if it is (which I doubt), the parse time is typically dwarfed by the time it takes to actually execute the request, so it doesn't matter.
HTTP is stateless, and the first thing every application does is roll its own half-baked session state management
This frustrates me too, but you can hardly blame it on SOAP. It's just a fundamental conflict between HTTP (stateless) and OOP (stateful).
Constructing a SOAP request using printf() would be an absurd waste of time. Anyone with a clue will use a toolkit library, and a toolkit that generates SOAP request documents could generate IIOP/ASN.1/DCE/JRMP requests just as easily.
Okay, let's come back here in a year. You can then count up all the publicly availble IIOP/ASN.1/DCE/JRMP services, and I'll count up all the SOAP web services. The proof's in the pudding, and I'm pretty sure this pudding's gonna be made out of SOAP.
By hijacking HTTP (which extant firewalls treat liberally) You're making it much more difficult to selectively allow traffic based on its purpose.
Don't worry, sysadmins. SOAP mandates the use of a "SOAPAction" HTTP header in every call. Firewall admins can filter SOAP requests based on the value of this header.
500 bytes is a huge IIOP packet. The same semantic could probably be expressed using 1/10 of a bandwidth in CORBA.
Yeah, but CORBA is much heavier than SOAP. SOAP is just a wire protocol, not a full-blown distributed object architecture. CORBA is more powerful, but it requires much more of the participants and is less scalable. All you need to do SOAP is XML and HTTP.
What if you want to stream video? Or have real-time quake session?
I agree with you here -- don't use SOAP. SOAP is for loosely-coupled applications, not real-time.
Because if all you want is to buy roses, frankly I don't see what's wrong with the current HTML-Form post.
What's wrong is that (as you said farther on) HTML was not designed for RPC. SOAP is. HTML is great for browsing, but's it's lousy for application-to-application interaction. So if you're using a browser to buy roses, by all means, use HTML over HTTP. But if you want to expose a programmable object that implements a BuyRoses(int Number) method, who wants to "screen scrape" the resulting HTML page to look for the paragraph/table/whatever that contains the confirmation number that gets sent back?
Why do you insist on comparing this to HTML?
I'm comparing SOAP to HTML because you're complaining that XML over HTTP is a waste of resources. I'm merely pointing out that it's no more a waste of resources than HTML over HTTP, which is the foundation of today's Internet.
HTML was never designed for RPC. IIOP is.
I never said HTML was designed for RPC. I'm saying that HTTP makes a fine transport protocol for RPC, and that SOAP over HTTP is no more expensive than HTML over HTTP.
How is it more scalable or flexible then CORBA? Any proof?
Well, aside from requiring ORBs and God-knows-what-other supporting software, CORBA (implicitly) implements a stateful programming model. SOAP doesn't.
I'll throw your challenge back at you. If CORBA is so scalable and flexible, where are all the video-streaming, Quake-playing CORBA servers on the Internet? I can point you to firewall-friendly SOAP web services that are exposed on the public Internet today. Are there any such services implemented using CORBA?
Slashdot Mirror
The conservatives are concentrating on fixing things for the kids while the liberals are concentrating on fixing the system.
If you pull the kids out of dangerous, broken schools and put them into better ones, the kids start getting a better education immediately.
I can't disagree with that, but it's only a short-term win. I think you need to look at the long-term too. Yanking everyone out of the public school system will distroy it.
-- Brian
It wouldn't need fixing at all if "intelligent liberals" hadn't broken it to begin with.
As most conservatives are quick to point out, the K-12 education system is under local, not federal, control. So it's hard to see how you can blame the breakage on the federal DoE.
-- Brian
The conservatives in the US are horrified at the k-12 educational system.
So are the (intelligent) liberals. The difference is that the conservatives want to give up on public education (via vouchers) while the liberals want to fix it.
-- Brian
Excellent troll. Claiming that there is as much logic in football as in chess. Brilliant.
-- Brian
Alright, here you go.
Don't confuse the .NET marketing blitz with the .NET framework. It's probably true that some of the back office products are getting gratiutiously slapped with the .NET moniker (Exchange.NET, anyone?).
.NET framework and tools (e.g. the Common Language Specification [CLS] and Common Language Runtime [CLR], Assemblies, etc.) are a completely real and completely new platform. Microsoft is turning their ship around on a dime again and anyone with an ounce of objectivity has got to be impressed (even if you prefer writing Java or C++ or ksh93 scripts in the end).
On the other hand, the
-- Brian
Perfect. Nailed him.
I think his only excuse may be that the Wired article is fairly old (from 1993).
-- Brian
I was weaned on Unix systems many years ago and have been assimilated into the Windows world since. Reading this definitely makes me nostalgic for the well-defined old days. One good thing I can say for Windows, however, is that it is finally taking Korn's advice to allow via scripting (e.g. the Windows Scripting Host) most things that can be accomplished via the GUI.
-- Brian
Get a clue. The .NET development environment is in Beta right now. I guess "vapor" isn't what it used to be.
-- Brian
Prisoners dilemma is nothing like poker
The Skittles game described above is a zero-sum game: Some number of Skittles come into the room (with the teacher) and the same number of Skittles leave the room (with the teacher and the kids). Note that the teacher is part of the game.
In the above example, the kids were NOT competeing for the skittles
Of course they are. They're just not competing against each other for Skittles.
A skittle for you does not come out of the mouth of another student, it comes from the "banker" of the game.
Exactly. And that's who the kids are competing against. The fact that they have to cooperate with each other in order to obtain Skittles is just an indirect outcome of the competition with the banker.
The point is that even the most selfish (but intellegint) jerk will cooperate with his "opponent" in order to get Skittles. The person who wrote the message I was responding to completely missed this point.
-- Brian
Amazing, you missed the point completely. I'd love to play some poker with you.
The teacher's lesson is not about cooperation instead of competing. It's about competing, and realizing what you are competing for.
So what are these kids competing for? In your mind, they are competing for some sort of abstract "victory" points. But anyone with a brain will eventually realize that victories have no intrinsic value. Pay attention now: The only thing worth accumulating in this game is SKITTLES.
The kids who cooperated got the most Skittles -- more Skittles even than the kids who won every turn. Repeat this to yourself until it sets in.
Your analogy to poker is perfect, and yet you still missed the point. When you play poker are you a) trying to win the most hands?, or b) trying to win the most money? Hint: $$$.
-- Brian
In the modern world the UI (be it a CLI or a GUI) is part of the OS. So if you get rid of the OS, you get rid of the the UI.
By your way of thinking, Linux would consist of nothing but the kernel.
-- Brian
It's mathematically impossible for the dual-proc compile to be "142% faster" than the single-proc compile. Anything more than 100% faster indicates that it takes less than no time.
For example:
Single-proc compile: 100 seconds
Dual-proc compile: 25 seconds
In this case, the dual-proc compile is 75% faster than the single-proc compile. Conversely, the single-proc compile is 300% (4x-1x) slower than the multi-proc compile.
The math for the first calculation is: (1x - (1/4)x) = 75%
Flip this around and you get the math for the second calculation: (4x - 1x) = 300%
I know this is counter-intuitive for some people, but that's how percents work in the real world. Don't blame me.
-- Brian
The OS currently provides consistency, but that doesn't mean consistency has to disappear with the OS crutch gone. Developers just have to get organized.
Okay. And after these hypothetical developers "get organized" around a consistent UI, what would happen next?
Well, of course they would then agree on a common implementation toolkit for the UI (in order to save work, promote reusability, etc.).
What next? They would then have the bright idea of shipping the implementation toolkit with every copy of the computer (in order to make life easier for the customer).
And what do they have then? Why, it's an operating system!
Shocking, isn't it?
-- Brian
No, no. We attack riding on top-secret "Ginger" prototypes!
-- Brian
Copyright Douglas Adams.
"Pointer clobbering" may be the cause of many an access violation, but I've not seen any exploits based on it. Do you know of any?
-- Brian
Hear, hear! Folks, if you write C++, learn the STL (which is now part of the language itself).
Unfortunately, in practice most C++ developers write code that is nearly indistinguishable from C. Hence the never-ending stream of new buffer overflow exploits.
-- Brian
Blaming the tool for the person using it's criminal intent is not the answer.
Criminy, no one is blaming the tool. We blame the criminals and thus seek to prevent them from using the tool to commit crimes in the future.
Aside from being unconstitutional (in the US), this seems like a perfectly reasonable plan. Why is it so hard for you to understand?
-- Brian
This is very entertaining. I appreciate you sharing the story of your incipient mental breakdown with everyone here at Slashdot.
Please do let us know what you think of next.
-- Brian
Interesting point. I thought many firewalls already inspected HTTP headers for this sort of stuff, but I guess not. Have to admit that I'm not a firewall expert. I can tell you for sure that SOAPAction was designed with this intent in mind. At least SOAPAction is case-sensitive, so you don't have to worry about that.<grin>
-- Brian
1) CORBA object can be made stateless too, you know. It's up to a system designer. Inability to use state actually is a big disadvantage in some systems as performance suffers and implementation gets complicated. CORBA gives you a choice. SOAP doesn't.
You can implement a stateful architecture on top of SOAP, it just doesn't force you to. I guess it's just a question of whether it's easier to add state to SOAP or remove state from CORBA. You may be right about CORBA in theory, but in practice SOAP is so simple that its rapid adoption will simply render the question moot.
2) With SOAP you need at least a full blown web server and XML-DOM parser. ORB-runtime usually is just a shared library.
Okay, but in a few years, every friggin' toaster sold by Target will have a "full blown" web server and an XML parser. Just about every server on the Internet today is already listening for HTTP on Port 80. What's the big deal?
3) IIOP can be tunneled through HTTP as easily as anything else. There are plenty of IIOP/HTTP gateways. Why reinvent the wheel when this is so easy?
Okay, but then where are all the CORBA web services on today's Internet? For one reason or another, people are not doing this. You tell me why.
-- Brian
XML is hugely more expensive to parse than even multipart/form-data, much less application/x-www-form-urlencoded.
Even if it is (which I doubt), the parse time is typically dwarfed by the time it takes to actually execute the request, so it doesn't matter.
HTTP is stateless, and the first thing every application does is roll its own half-baked session state management
This frustrates me too, but you can hardly blame it on SOAP. It's just a fundamental conflict between HTTP (stateless) and OOP (stateful).
Constructing a SOAP request using printf() would be an absurd waste of time. Anyone with a clue will use a toolkit library, and a toolkit that generates SOAP request documents could generate IIOP/ASN.1/DCE/JRMP requests just as easily.
Okay, let's come back here in a year. You can then count up all the publicly availble IIOP/ASN.1/DCE/JRMP services, and I'll count up all the SOAP web services. The proof's in the pudding, and I'm pretty sure this pudding's gonna be made out of SOAP.
-- Brian
By hijacking HTTP (which extant firewalls treat liberally) You're making it much more difficult to selectively allow traffic based on its purpose.
Don't worry, sysadmins. SOAP mandates the use of a "SOAPAction" HTTP header in every call. Firewall admins can filter SOAP requests based on the value of this header.
-- Brian
500 bytes is a huge IIOP packet. The same semantic could probably be expressed using 1/10 of a bandwidth in CORBA.
Yeah, but CORBA is much heavier than SOAP. SOAP is just a wire protocol, not a full-blown distributed object architecture. CORBA is more powerful, but it requires much more of the participants and is less scalable. All you need to do SOAP is XML and HTTP.
What if you want to stream video? Or have real-time quake session?
I agree with you here -- don't use SOAP. SOAP is for loosely-coupled applications, not real-time.
Because if all you want is to buy roses, frankly I don't see what's wrong with the current HTML-Form post.
What's wrong is that (as you said farther on) HTML was not designed for RPC. SOAP is. HTML is great for browsing, but's it's lousy for application-to-application interaction. So if you're using a browser to buy roses, by all means, use HTML over HTTP. But if you want to expose a programmable object that implements a BuyRoses(int Number) method, who wants to "screen scrape" the resulting HTML page to look for the paragraph/table/whatever that contains the confirmation number that gets sent back?
Why do you insist on comparing this to HTML?
I'm comparing SOAP to HTML because you're complaining that XML over HTTP is a waste of resources. I'm merely pointing out that it's no more a waste of resources than HTML over HTTP, which is the foundation of today's Internet.
HTML was never designed for RPC. IIOP is.
I never said HTML was designed for RPC. I'm saying that HTTP makes a fine transport protocol for RPC, and that SOAP over HTTP is no more expensive than HTML over HTTP.
How is it more scalable or flexible then CORBA? Any proof?
Well, aside from requiring ORBs and God-knows-what-other supporting software, CORBA (implicitly) implements a stateful programming model. SOAP doesn't.
I'll throw your challenge back at you. If CORBA is so scalable and flexible, where are all the video-streaming, Quake-playing CORBA servers on the Internet? I can point you to firewall-friendly SOAP web services that are exposed on the public Internet today. Are there any such services implemented using CORBA?
-- Brian