I don't post much so my Karma is fairly hard won but I'm going to troll anyway.
There is so much stupid shit being said in response to this article that I have to offer some advice to those without a clue:
1) For God's sake go learn a language (like C/C++ or assembly) where you can do some real damage. I'm conviced nobody truely "gets" software until they've spent three sleepless nights in a row tracking down a fandango on core.
2) Really grok a language that changes your way of thinking -- Haskell is a pretty good bet.
3) Dig up old hardware take it apart, put it back together. Get it to work again.
4) Use a hardware assisted debugger or in circuit emulator.
5) Go build and a small 8051 embedded system project just for fun but make sure you include an LCD display in the project -- and not just one of the easy serial type.
6) Buy a cheap scope -- Before you go insane from step 5.
7) Learn what happens under to the covers.
8) Say "Fuck the Wizard and the IDE you rode in on too."
9) Learn VHDL and digital design just for the heck of it These folks have everything you need.
If you've done this, you've learned a lot. But after all that, think about the things you still don't know. Marvell at your stupidity -- admit it openly. Be humbled. You will be a better person for it.
In short, don't become just another button pushing pinhead. You don't have to live that way.
Oh, and if you're one of the few that have taken the time and effort to become aware of how much you don't know, thank you. You are a credit to the profession.
There are very few application that don't reach out across a network for information. The bottleneck is usually this network communications. Check out Performant for tools that work on the network level.
There's also a continuing trend of software developers spending user's computing power to make thier jobs easier. Java, J2EE, C#,.NET, C++, C all can theoretically produce software that is just as speedy as assembly but it rarely is. People still write assembly where performance really counts (games, realtime, etc.)
Some people thinks that the wasted processing power is a crime. Me, I think it's just economics. It's much cheaper to pay for processing power than it is to pay for the developers to squeeze every last bit of performance out of an app.
However, there are some applications where profiling is absolutely required. Database engines, games, simulations, anything that is CPU-bound has the potential of benifiting from profiling.
They don't write code for environments what has APIs as messed up as Windows. For a good example, look at CreateProcess Vs. fork()
Granted you may have to string together multiple different calls (i.e. fork + exec + setuid) under Unix to get the job done but at least every possible permutation for every possible situation isn't in your face as required parameters everytime you try to spawn a child process.
That aside -- I don't like writing Win32 code without Intellisense. Visual Studio.NET is darn cool. BTW, my favorite IDE under Unix is EMACS. Until VS.NET my favorite IDE under Windows was EMACS.
Re:OpenGL Matrix Stack
on
Pet Bugs?
·
· Score: 2, Informative
Actually, your OpenGL implementation is supposed to give you and error back. You have to call glGetError() to get it. In this case it should return GL_STACK_OVERFLOW.
I know first hand that this works under WindowsXP with the nVidia drivers. Not that the drivers should have anything to do with it.
As an aside, you should call glGetError() in a loop. There may be multiple errors waiting.
So either you had a broken OpenGL implementation or just forgot to call glGetError(). Anyway, just thought I'd point out that this isn't a generic OpenGL problem.
Code Scope and Duff's Device
on
Pet Bugs?
·
· Score: 1
About 10 years ago there was a debugger called Code Scope (I think that was the name). Anyway, if you compiled up Duff's Device with MSC and stepped through it in the debugger, it didn't execute correctly. However, if you just set a breakpoint at the end, it would run fine.
I was asked to evaluate the debugger for general deployment and after I tried this, I had to pass.
As far as most anoying bug -- about any MSC version before 6.0 and try
func(i > 0 ? Class1() : Class2());
Basically the lifetime of temporary objects was pretty messed up -- especially when combined with the ternary operator.
Re:Poisoned technology again
on
Web Services
·
· Score: 1
I can't tell if I'm feeding a troll or not, but here goes:
"Web services standards" are robbing network programming from its greatest advantages -- possibility of asynchronous processing, data transparency and flexibility in the data models.
XML is transparent. It's text. Granted it's unicode text. If you don't like it, use UTF-8 and play like unicode doesn't exist. Just don't expect anybody to sympathize if you're system breaks when a Japanese company tries to use it. Unicode isn't a big deal to use, really. Trust me.
Programmers don't neet SOAP or RPC of any kind, they need data encapsulation standard, and one that is not tied to poisoned technology such as XML, Unicode ot Java (yes, those are "open standards"
Okay, what's the difference between SOAP and a "data encapsulation standard". You do realize that SOAP isn't just RPC. You can use any XML encoding you like inside the data payload not just RPC encoding.
, but they are stuffed with idiosyncrasy of their developers and therefore promote all kinds of ideas, in my opinion, stupid ones, over other ideas that are superior for a lot of applications, yet excluded and made impossible to implement over narrow-minded standards).
Care for an example?
Imagine a standard that only allows to address the service by sending HTTP-like request
I can. It's called HTTP.
yet then the connection transforms into a asynchronous bidirectional one, with possibility to stream data in both directions -- with ot without synchronization.
Granted this is difficult to do. Streaming data one direction at a time over http is easy. Streaming it both directions is not. Can you cite an application where you'd want to stream in both directions at the same time? In my experience, most applications need to request something then receive back a response.
Imagine "document" that is just like XML, but without all the Unicode crap (data is transparent -- if one wants to use unicode, mark it as unicode, and make software aware of it, otherwise just don't),
I consider unicode transparent. I have editors that work just fine with Unicode. Emacs on Unix and wordpad on Windows. If you don't want your document to have non-ascii characters in them, mark them as UTF-8 and just write them out as ASCII. Not hard. You will have problems with people trying to send you text that contains non-ASCII characters but you have that problem with ASCII. Do it like this:
<?xml version="1.0" encoding="UTF-8"?>
without end of document, so data can be streamed endlessly and become available as the tags/fields are parsed.
You can do this with XML and SOAP. There absolutely no reason that you have to wait for the entire document to get at the data. If you're using an implementation that loads everything into a DOM before you get a whack at it, find another implementation. It's not a protocol problem.
This would be far superior for any imaginable purpose to all those little "standards" that Microsoft and Sun originate, and W3C ruberstamps by dozens, that would be a truly useful tool that will improve network programming.
This only time when it would be superior is when you wanted to stream data in both directions at the same time.
You forgot IBM, MIT, Canon, HP, IONA, and Akamai. All have contributed to the SOAP standardization efforts.
However I don't believe any software company will now work on it -- no idiosyncrasy in the standard means no advantage, monetary or political, to its originator over everyone else.
That may be true. It's hard to get someone interrested in a protocol that isn't part of an existing standard.
Only truly free software/opensource/open standards project would be able to accomplish this. I am just afraid that people won't realize this until it will be too late.
YOU have realized it! Now it's time to make it happen. If you truely have something better, post a link to it as a reply to this message. It's great advertisement for your project and could bring you lot of new like-minded developers.
I'm dubious about your claims. That's just because I happen to like SOAP. It can be a little daunting to understand all the technologies involved in using SOAP but no more so than CORBA, DCE-RPC, SUN RPC, SMB or any other network protocol. I'd love to see you step up and actually post a link to a technical document that explains what you're talking about.
Too bad you're an AC. Nice job expecialy for someone who just started looking at web services.
Re:Web Services = Inherently Insecure
on
Web Services
·
· Score: 3, Insightful
I'm tired of this crap. Let's put the shoe on the other foot. If you were going to accomplish the same task (letting customers access an API publish by your company) how would you do it?
Here are the choices as I see it:
1) Use CORBA. You have to bust a whole in the firewall. I don't know about you, but I would much rather trust an HTTP server than most CORBA Orbs I've seen. Grab the source to one and start poking. Look at the marshalling code in particular. There's also no provision for encryption in the IIOP standards, big problems for any NAT equipment, the list just goes on and on.
2) Use DCOM -- Yech
3) Use a custom protocol. Sorry but most programmers mess up network programming pretty bad not gonna trust this one.
4) Use EDI -- if you are seriously considering this one, get out a baseball bat, bash youself in the head, rinse, lather, repeat until it's all better.
5) Build a private network. This is expensive and troublesome. Using HTTPS with authentication is probably a better solutions.
This crap about web services being inherently insecure is usually based on running web services over port 80 or 443. If you really want to, you can run it over any port you like. HTTP communication endpoints are specified using essentially URLs, so http://www.example.org:8325/myservice. Uses port 8325. Now you can firewall all you want.
Other people think that web servers are getting exploited all the time so you shouldn't use them. IIS aside, most of the popular web servers have become more secure as a result of the attacks. I don't know of a single ORB or custom protocol implementation that's withstood the trypes of attacks that web servers have. So I feel more comfortable putting something out there that's been battle tested.
I think I've covered most of the options. If you have others that you think are better, I'm certainly open to hearing them. Just remember, not letting users have access to the APIs is not an option.
Tivo doesn't make money on hardware...
on
PVR For Linux
·
· Score: 1
They make money on the service. In fact, they've been subsidizing the production cost of the hardware.
I think it would be smart of TiVo to open up their service to subscribers as a SOAP service. This would let them focus on revenue from the service and give the OpenSource community a good listing source. Granted you would still have to subscribe but you could use and hardware or software you wanted.
Running Tyan Tiger dual AMD for 3 months under WinXP. Not a single hardware problem. I reboot ocassionally but it's usually some strange software problem.
Absolutely! Once projects get above about 3 people somebody has to be the grown-up. Linus is the grown-up for Linux. You've been the grown up for your projects. I've been the grown up for teams of 35 people shipping 4 different products - I had help, of course.
This team seems to lack a grown-up.
No tool can play grown-up for a project. My first job, everybody on the team was a grown-up except me (give me a break I was 19 and it as my first programming job). That team did it all without version control tools. Not the best way by far but it can happen.
On the other hand, my second programming job was for a bank that used PVCS. They were missing grown-ups so a lot of their projects crashed and burned.
>The human eye cannot distinguish images at >more than 30 Hz, just like the human hear >sounds over 20KHz. Yet for hi-fi audio, the >bare minimum is considered 44.1 KHz, with >48 KHz and beyond being preferred.
<SNIP>
44.1KHz and 48KHz are the standard sampling rates for CD and DAT respectively. Nyquist Frequency and all that. Here's a reference. Either you're having a bad day or are in need of a severe beating.
BTW, the current hot item in the digital audio world is 96Khz sampling rates. I don't know of a single instance of a human being able to distinguish 48Khz frequency tones. I can't explain it -- but then again the audio industry has never been ruled by logic.
Generally VCs get out at or shortly after the IPO. It's the large institutional investors (read pension funds) that end up getting stuck holding the bag. The VCs and thier LPs got thier money back many times over and are generally long gone.
VCs invest in very risky, very high growth companies. They expect a 100x return on investment becasue they know that only one in 20 is going to make it. 5x investment overall isn't bad but you have to invest in a lot of companies in order for it to work out. Once a company IPOs, 100x returns just aren't there. And besides, I want VCs investing in high risk stuff. There are plenty of stock brokers out there to take care of investing in the companies that have already made the transition from private to public.
So weep not for the VCs but don't curse them either.
It depends on what you're doing with it. If you want to go a few thousands of miles without chain goo slinging off onto your nice, clean Kilamanjaro Jacket then shaft drive is the way to go.
However, shaft driven bikes (with the exception of some BMWs) exhibit "shaft-jacking" meaning that the back end of the bike will lift up an extra inch or so under heavy acceleration making the suspension less pliant and potentially upsetting a rider who pushing the bike hard.
Belts, (IMHO) just don't cut it. There's a reason why you don't see them on world superbike machines. The only roadracing bikes to use them are Buells. But they're a segregated into a seperate class.
Chains, however, seem to handle the 170HP of a Honda SP2 racebike (2001 SP1 Specs) just fine.
Yes, I'm a geek -- even about cool stuff like motorcycles.
Okay, I've worked for two different network model database companies -- the network database model is just an extension of the network model to allow graph schemas instead of a strict hierarchy. I've also worked with two companies that we mapping hierarchical structures onto relational databases.
You can think of data structures as (leaving ternary relationships and such aside) some sort of network of relationships. When you think of it this way, relational and network model databases have more similarities than they have differences, especially when you consider that using surrogate keys is the moral equivalent of a network model "pointer".
Okay so you have this network of relationships, mapping a hierarchical structure onto that is simply picking a starting point and traversing the structure from that "viewpoint" without visiting a node via the same relationship twice (simplified algorithm but...) One of these groups used to think about this like you had a multi-legged turkey. You grab one leg and hold it up. All the other legs hang down -- you grab another leg and a different set of legs hang down.
So, if you buy that, does it really make sense to represent any sort of network of information in a hierarchical form? Well, yes and no. It makes sense from a presentation and maybe interchange perspective but not from a native storage perspective. It's simply to constrictive and you and up representing relationships that don't fit into a neat hierarchy programmatically in the application code instead of explicitly in the database schema. 25 years from now, someone is trying to reverse engineer your code and figure out how all this data is related -- blech. Ever wonder why IMS application are generally left alone and newer applications are not usually written to IMS. This is part of the reason why. (yes there are some but they are the exception).
Throw in to this my experience working with a bank that had hierarchical data and the extent to which they went to circumvent that restriction, and I'd say that native hierarchical storage for XML is a bad idea. Granted it's tempting but it seems ill advised since it's very likely that your data will survive long beyond the lifecycle of the system used to originally store it.
<RANT>
The original question didn't provoke this but I've seen a couple of responses about using XML as a native data storage format. Let me say that, unless the data is very static, it's a monumentally stupid idea to do that. XML is not a replacement for a database.
I find that most of the people who really want to do this are ignorant of all the work that goes into real database systems. They don't understand lock management, transactions, rollback and recovery, free space management nor the scalability issue that real databases take care of under the covers. If you feel tempted read this
You throw this plus the representation of non-hierarchical relationship with IDs and sooner or later you will find yourself in a text editor tracking down ID/IDREF pairs to find out where your data is corrupted. Or writing scripts to validate your "entire data set" -- above a few megabytes it can be really painful.
For God's sake, expect to use XML to store data that you are going to update with any regularity.
</RANT>
The problem with IIOP and DRPC is that they encode the communication enpoints as a hard IP address and port in the requests on the wire.
This makes these products virtually incompatable with network address translation (NAT) out of the box. Basically, the NAT boxes will translate a local, non-routable IP address into the IP address of the NAT box with a made-up port number. The problem is they don't modify the IP address and port numbers imbedded into the IIOP message.
There are products that will do this but you have a choice: 1) Teach your admins about another product and install the product both at your site and the client site or 2) teach them how to secure web services using the existing firewalls, load balancers, and SSL that they already understand -- no client site modifications required.
Securing web services properly (IMHO) requires that you have a layer 7 device that can look at the incoming SOAP requests and dump requests for an unknown endpoint on the floor immediately. The you have to make sure the request gets properly validated by the SOAP implementation and application layer.
So on the one hand you have IIOP and DRPC that require additional products or you have SOAP with requires you to apply the products that, if you have a significant web presence, you already have. Seems like an easy choice to me but you have to understand how all the pieces fit together. If you don't have that expertise in house, go rent it from somewhere.
SOAP implementation are required to check the HTTP header against the requests. This means that you can take an F5 box or firewall, dump anything that doesn't have the right header on the floor.
Now the request gets to the server. It's guaranteed to have the right HTTP header. The SOAP implementation is required to validate the header against the request and possibly validates the entire thing against an XML schema.
Now at the application level you know that 1) You have a request for a valid SOAP Service and 2) It is a well formed request that's been structurally validated. So the application can now validate the semantics of the request. Making sure that you aren't asking for an invoice the doesn't belong to you -- those sorts of application specific checks.
The point is the header specifies the SOAP service which can be filtered on a firewall and the SOAP Envelope contains enough information to cross check and validate the endpoint and request back at the server level. There's plenty there to work with. How many "I only allow port 80 and 443)" admins will understand this, I don't know but running it over port 80 is emphatically not about the server side.
Coupled with the fact that you can run this over SSL with client-side certs can make it pretty secure.
Yep, I know what you mean. I advertised with Google Adwords on a bunch of computer skils that I specialize in. You see -- I'm a computer consultant. CHose to emphasis the skills that I though were both fun and did well at driving
traffic. It's an excellent market research tool.
I once worked on a software project with a very high advertising budget. The people that ran it always talked about the importance of trying something, testing the results, and adjusting. Things like this give us little guys a really easy way to do it without breaking the bank.
Building software and physical structures are two entirely different things:
1) The customer of a construction company is unlikely to decide that their cute split-level should now be a super mall after construction is underway. It isn't unusual to see the equivalent happen in software.
2) The "Mythical Man Month" presents a pretty good argument about fundamental complexity Vs. accidental complexity. It would be a good thing to think about.
3) Because everyone has a passing familiarity with the physical world things that aren't right get pointed out fairly quickly. In my experience is that about 20-30% of programmers can cut through the symptoms and treat the cause. Everybody else goes around plastering over cracks instead of realizing that the foundation is crumbling.
A vast majority of the performance gains to be had from stored procedure programming comes from two sources -- precompilation and elimination of network round trips.
Neither of these options are precluded by a correct abstract interface.
There's no doubt that such an abstract interface would hurt performance, but I would venture to say that you would give back much less than 1% of the stored procedure benefits by doing this. You can do a large number of JNI-Like calls in the ~8ms required to complete a network round trip. Add compilation and query optimization and you have a large number Vs. a very small number.
To be able to provide a migration path for both sers of MS SQL Server/Sybase, Oracle, and DB/2 seems compelling even though and such migration path is likely to be an 80/20 proposition.
I've had to reboot my cable modem recently every night to restore connectivity. My ISP just sent out an email saying the CISCO cable modem that I'm using hammered by Code Red.
Here's the quote "With the Cisco 67x series, as well as HP print servers, 3Com switches, and almost all other embedded web server applications, the worm causes a buffer overrun which causes the device to lock up."
Is this really true? It seems pretty unlikely that almost all embedded web server application have a buffer overrun. It seems possible that a few devices do.
I haven't used Windows XP but I have a question since you seem to have some experience with it.
Will Microsoft really send program crashdumps for non-Microsoft programs? If transmission of the equivelant of core dumps to Microsoft is something that the application developer can't control, there's a real problem.
Let's assume that I'm working for an independent software vendor and someone in the QA department makes a mistake and presses the wrong button. Boom, MS has a memory image of our new super secret software system.
That's a bad thing. Please tell me hat MS hasn't done this.
I already know people who are refusing to use XP (Windows or Office) because of the activation issues. These are people who spend a lot of time in Singapore and fly with *EVERY* CD, Serial number, CD-KEY -- Literally everything that they need to rebuild the machine. About once a year they have a problem and rebuild the machine -- they don't carry this stuff just in case.
Since these are software development types, this bit of news will even go down less well.
Slashdot Mirror
I don't post much so my Karma is fairly hard won but I'm going to troll anyway.
There is so much stupid shit being said in response to this article that I have to offer some advice to those without a clue:
1) For God's sake go learn a language (like C/C++ or assembly) where you can do some real damage. I'm conviced nobody truely "gets" software until they've spent three sleepless nights in a row tracking down a fandango on core.
2) Really grok a language that changes your way of thinking -- Haskell is a pretty good bet.
3) Dig up old hardware take it apart, put it back together. Get it to work again.
4) Use a hardware assisted debugger or in circuit emulator.
5) Go build and a small 8051 embedded system project just for fun but make sure you include an LCD display in the project -- and not just one of the easy serial type.
6) Buy a cheap scope -- Before you go insane from step 5.
7) Learn what happens under to the covers.
8) Say "Fuck the Wizard and the IDE you rode in on too."
9) Learn VHDL and digital design just for the heck of it These folks have everything you need.
If you've done this, you've learned a lot. But after all that, think about the things you still don't know. Marvell at your stupidity -- admit it openly. Be humbled. You will be a better person for it.
In short, don't become just another button pushing pinhead. You don't have to live that way.
Oh, and if you're one of the few that have taken the time and effort to become aware of how much you don't know, thank you. You are a credit to the profession.
There are very few application that don't reach out across a network for information. The bottleneck is usually this network communications. Check out Performant for tools that work on the network level.
.NET, C++, C all can theoretically produce software that is just as speedy as assembly but it rarely is. People still write assembly where performance really counts (games, realtime, etc.)
There's also a continuing trend of software developers spending user's computing power to make thier jobs easier. Java, J2EE, C#,
Some people thinks that the wasted processing power is a crime. Me, I think it's just economics. It's much cheaper to pay for processing power than it is to pay for the developers to squeeze every last bit of performance out of an app.
However, there are some applications where profiling is absolutely required. Database engines, games, simulations, anything that is CPU-bound has the potential of benifiting from profiling.
They don't write code for environments what has APIs as messed up as Windows. For a good example, look at CreateProcess Vs. fork()
Granted you may have to string together multiple different calls (i.e. fork + exec + setuid) under Unix to get the job done but at least every possible permutation for every possible situation isn't in your face as required parameters everytime you try to spawn a child process.
That aside -- I don't like writing Win32 code without Intellisense. Visual Studio.NET is darn cool. BTW, my favorite IDE under Unix is EMACS. Until VS.NET my favorite IDE under Windows was EMACS.
Actually, your OpenGL implementation is supposed to give you and error back. You have to call glGetError() to get it. In this case it should return GL_STACK_OVERFLOW.
I know first hand that this works under WindowsXP with the nVidia drivers. Not that the drivers should have anything to do with it.
As an aside, you should call glGetError() in a loop. There may be multiple errors waiting.
So either you had a broken OpenGL implementation or just forgot to call glGetError(). Anyway, just thought I'd point out that this isn't a generic OpenGL problem.
About 10 years ago there was a debugger called Code Scope (I think that was the name). Anyway, if you compiled up Duff's Device with MSC and stepped through it in the debugger, it didn't execute correctly. However, if you just set a breakpoint at the end, it would run fine.
I was asked to evaluate the debugger for general deployment and after I tried this, I had to pass.
As far as most anoying bug -- about any MSC version before 6.0 and try
func(i > 0 ? Class1() : Class2());
Basically the lifetime of temporary objects was pretty messed up -- especially when combined with the ternary operator.
I can't tell if I'm feeding a troll or not, but here goes:
"Web services standards" are robbing network programming from its greatest advantages -- possibility of asynchronous processing, data transparency and flexibility in the data models.
XML is transparent. It's text. Granted it's unicode text. If you don't like it, use UTF-8 and play like unicode doesn't exist. Just don't expect anybody to sympathize if you're system breaks when a Japanese company tries to use it. Unicode isn't a big deal to use, really. Trust me.
Programmers don't neet SOAP or RPC of any kind, they need data encapsulation standard, and one that is not tied to poisoned technology such as XML, Unicode ot Java (yes, those are "open standards"
Okay, what's the difference between SOAP and a "data encapsulation standard". You do realize that SOAP isn't just RPC. You can use any XML encoding you like inside the data payload not just RPC encoding.
, but they are stuffed with idiosyncrasy of their developers and therefore promote all kinds of ideas, in my opinion, stupid ones, over other ideas that are superior for a lot of applications, yet excluded and made impossible to implement over narrow-minded standards).
Care for an example?
Imagine a standard that only allows to address the service by sending HTTP-like request
I can. It's called HTTP.
yet then the connection transforms into a asynchronous bidirectional one, with possibility to stream data in both directions -- with ot without synchronization.
Granted this is difficult to do. Streaming data one direction at a time over http is easy. Streaming it both directions is not. Can you cite an application where you'd want to stream in both directions at the same time? In my experience, most applications need to request something then receive back a response.
Imagine "document" that is just like XML, but without all the Unicode crap (data is transparent -- if one wants to use unicode, mark it as unicode, and make software aware of it, otherwise just don't),
I consider unicode transparent. I have editors that work just fine with Unicode. Emacs on Unix and wordpad on Windows. If you don't want your document to have non-ascii characters in them, mark them as UTF-8 and just write them out as ASCII. Not hard. You will have problems with people trying to send you text that contains non-ASCII characters but you have that problem with ASCII. Do it like this: <?xml version="1.0" encoding="UTF-8"?>
without end of document, so data can be streamed endlessly and become available as the tags/fields are parsed.
You can do this with XML and SOAP. There absolutely no reason that you have to wait for the entire document to get at the data. If you're using an implementation that loads everything into a DOM before you get a whack at it, find another implementation. It's not a protocol problem. This would be far superior for any imaginable purpose to all those little "standards" that Microsoft and Sun originate, and W3C ruberstamps by dozens, that would be a truly useful tool that will improve network programming. This only time when it would be superior is when you wanted to stream data in both directions at the same time. You forgot IBM, MIT, Canon, HP, IONA, and Akamai. All have contributed to the SOAP standardization efforts.
However I don't believe any software company will now work on it -- no idiosyncrasy in the standard means no advantage, monetary or political, to its originator over everyone else.
That may be true. It's hard to get someone interrested in a protocol that isn't part of an existing standard.
Only truly free software/opensource/open standards project would be able to accomplish this. I am just afraid that people won't realize this until it will be too late.
YOU have realized it! Now it's time to make it happen. If you truely have something better, post a link to it as a reply to this message. It's great advertisement for your project and could bring you lot of new like-minded developers.
I'm dubious about your claims. That's just because I happen to like SOAP. It can be a little daunting to understand all the technologies involved in using SOAP but no more so than CORBA, DCE-RPC, SUN RPC, SMB or any other network protocol. I'd love to see you step up and actually post a link to a technical document that explains what you're talking about.
Too bad you're an AC. Nice job expecialy for someone who just started looking at web services.
I'm tired of this crap. Let's put the shoe on the other foot. If you were going to accomplish the same task (letting customers access an API publish by your company) how would you do it?
Here are the choices as I see it:
1) Use CORBA. You have to bust a whole in the firewall. I don't know about you, but I would much rather trust an HTTP server than most CORBA Orbs I've seen. Grab the source to one and start poking. Look at the marshalling code in particular. There's also no provision for encryption in the IIOP standards, big problems for any NAT equipment, the list just goes on and on.
2) Use DCOM -- Yech
3) Use a custom protocol. Sorry but most programmers mess up network programming pretty bad not gonna trust this one.
4) Use EDI -- if you are seriously considering this one, get out a baseball bat, bash youself in the head, rinse, lather, repeat until it's all better.
5) Build a private network. This is expensive and troublesome. Using HTTPS with authentication is probably a better solutions.
This crap about web services being inherently insecure is usually based on running web services over port 80 or 443. If you really want to, you can run it over any port you like. HTTP communication endpoints are specified using essentially URLs, so http://www.example.org:8325/myservice. Uses port 8325. Now you can firewall all you want.
Other people think that web servers are getting exploited all the time so you shouldn't use them. IIS aside, most of the popular web servers have become more secure as a result of the attacks. I don't know of a single ORB or custom protocol implementation that's withstood the trypes of attacks that web servers have. So I feel more comfortable putting something out there that's been battle tested.
I think I've covered most of the options. If you have others that you think are better, I'm certainly open to hearing them. Just remember, not letting users have access to the APIs is not an option.
They make money on the service. In fact, they've been subsidizing the production cost of the hardware.
I think it would be smart of TiVo to open up their service to subscribers as a SOAP service. This would let them focus on revenue from the service and give the OpenSource community a good listing source. Granted you would still have to subscribe but you could use and hardware or software you wanted.
Running Tyan Tiger dual AMD for 3 months under WinXP. Not a single hardware problem. I reboot ocassionally but it's usually some strange software problem.
Good stuff, Maynard. You won't regret it.
Absolutely! Once projects get above about 3 people somebody has to be the grown-up. Linus is the grown-up for Linux. You've been the grown up for your projects. I've been the grown up for teams of 35 people shipping 4 different products - I had help, of course.
This team seems to lack a grown-up.
No tool can play grown-up for a project. My first job, everybody on the team was a grown-up except me (give me a break I was 19 and it as my first programming job). That team did it all without version control tools. Not the best way by far but it can happen.
On the other hand, my second programming job was for a bank that used PVCS. They were missing grown-ups so a lot of their projects crashed and burned.
>more than 30 Hz, just like the human hear
>sounds over 20KHz. Yet for hi-fi audio, the
>bare minimum is considered 44.1 KHz, with
>48 KHz and beyond being preferred.
<SNIP>
44.1KHz and 48KHz are the standard sampling rates for CD and DAT respectively. Nyquist Frequency and all that. Here's a reference. Either you're having a bad day or are in need of a severe beating.
BTW, the current hot item in the digital audio world is 96Khz sampling rates. I don't know of a single instance of a human being able to distinguish 48Khz frequency tones. I can't explain it -- but then again the audio industry has never been ruled by logic.
Generally VCs get out at or shortly after the IPO. It's the large institutional investors (read pension funds) that end up getting stuck holding the bag. The VCs and thier LPs got thier money back many times over and are generally long gone.
VCs invest in very risky, very high growth companies. They expect a 100x return on investment becasue they know that only one in 20 is going to make it. 5x investment overall isn't bad but you have to invest in a lot of companies in order for it to work out. Once a company IPOs, 100x returns just aren't there. And besides, I want VCs investing in high risk stuff. There are plenty of stock brokers out there to take care of investing in the companies that have already made the transition from private to public.
So weep not for the VCs but don't curse them either.
It depends on what you're doing with it. If you want to go a few thousands of miles without chain goo slinging off onto your nice, clean Kilamanjaro Jacket then shaft drive is the way to go.
However, shaft driven bikes (with the exception of some BMWs) exhibit "shaft-jacking" meaning that the back end of the bike will lift up an extra inch or so under heavy acceleration making the suspension less pliant and potentially upsetting a rider who pushing the bike hard.
Belts, (IMHO) just don't cut it. There's a reason why you don't see them on world superbike machines. The only roadracing bikes to use them are Buells. But they're a segregated into a seperate class.
Chains, however, seem to handle the 170HP of a Honda SP2 racebike (2001 SP1 Specs) just fine.
Yes, I'm a geek -- even about cool stuff like motorcycles.
Okay, I've worked for two different network model database companies -- the network database model is just an extension of the network model to allow graph schemas instead of a strict hierarchy. I've also worked with two companies that we mapping hierarchical structures onto relational databases.
You can think of data structures as (leaving ternary relationships and such aside) some sort of network of relationships. When you think of it this way, relational and network model databases have more similarities than they have differences, especially when you consider that using surrogate keys is the moral equivalent of a network model "pointer".
Okay so you have this network of relationships, mapping a hierarchical structure onto that is simply picking a starting point and traversing the structure from that "viewpoint" without visiting a node via the same relationship twice (simplified algorithm but...) One of these groups used to think about this like you had a multi-legged turkey. You grab one leg and hold it up. All the other legs hang down -- you grab another leg and a different set of legs hang down.
So, if you buy that, does it really make sense to represent any sort of network of information in a hierarchical form? Well, yes and no. It makes sense from a presentation and maybe interchange perspective but not from a native storage perspective. It's simply to constrictive and you and up representing relationships that don't fit into a neat hierarchy programmatically in the application code instead of explicitly in the database schema. 25 years from now, someone is trying to reverse engineer your code and figure out how all this data is related -- blech. Ever wonder why IMS application are generally left alone and newer applications are not usually written to IMS. This is part of the reason why. (yes there are some but they are the exception).
Throw in to this my experience working with a bank that had hierarchical data and the extent to which they went to circumvent that restriction, and I'd say that native hierarchical storage for XML is a bad idea. Granted it's tempting but it seems ill advised since it's very likely that your data will survive long beyond the lifecycle of the system used to originally store it.
<RANT>
The original question didn't provoke this but I've seen a couple of responses about using XML as a native data storage format. Let me say that, unless the data is very static, it's a monumentally stupid idea to do that. XML is not a replacement for a database.
I find that most of the people who really want to do this are ignorant of all the work that goes into real database systems. They don't understand lock management, transactions, rollback and recovery, free space management nor the scalability issue that real databases take care of under the covers. If you feel tempted read this
You throw this plus the representation of non-hierarchical relationship with IDs and sooner or later you will find yourself in a text editor tracking down ID/IDREF pairs to find out where your data is corrupted. Or writing scripts to validate your "entire data set" -- above a few megabytes it can be really painful.
For God's sake, expect to use XML to store data that you are going to update with any regularity.
</RANT>
The problem with IIOP and DRPC is that they encode the communication enpoints as a hard IP address and port in the requests on the wire.
This makes these products virtually incompatable with network address translation (NAT) out of the box. Basically, the NAT boxes will translate a local, non-routable IP address into the IP address of the NAT box with a made-up port number. The problem is they don't modify the IP address and port numbers imbedded into the IIOP message.
There are products that will do this but you have a choice: 1) Teach your admins about another product and install the product both at your site and the client site or 2) teach them how to secure web services using the existing firewalls, load balancers, and SSL that they already understand -- no client site modifications required.
Securing web services properly (IMHO) requires that you have a layer 7 device that can look at the incoming SOAP requests and dump requests for an unknown endpoint on the floor immediately. The you have to make sure the request gets properly validated by the SOAP implementation and application layer.
So on the one hand you have IIOP and DRPC that require additional products or you have SOAP with requires you to apply the products that, if you have a significant web presence, you already have. Seems like an easy choice to me but you have to understand how all the pieces fit together. If you don't have that expertise in house, go rent it from somewhere.
SOAP implementation are required to check the HTTP header against the requests. This means that you can take an F5 box or firewall, dump anything that doesn't have the right header on the floor.
Now the request gets to the server. It's guaranteed to have the right HTTP header. The SOAP implementation is required to validate the header against the request and possibly validates the entire thing against an XML schema.
Now at the application level you know that 1) You have a request for a valid SOAP Service and 2) It is a well formed request that's been structurally validated. So the application can now validate the semantics of the request. Making sure that you aren't asking for an invoice the doesn't belong to you -- those sorts of application specific checks.
The point is the header specifies the SOAP service which can be filtered on a firewall and the SOAP Envelope contains enough information to cross check and validate the endpoint and request back at the server level. There's plenty there to work with. How many "I only allow port 80 and 443)" admins will understand this, I don't know but running it over port 80 is emphatically not about the server side.
Coupled with the fact that you can run this over SSL with client-side certs can make it pretty secure.
traffic. It's an excellent market research tool.
I once worked on a software project with a very high advertising budget. The people that ran it always talked about the importance of trying something, testing the results, and adjusting. Things like this give us little guys a really easy way to do it without breaking the bank.
Google does the same thing:
Here is more info.
Building software and physical structures are two entirely different things:
1) The customer of a construction company is unlikely to decide that their cute split-level should now be a super mall after construction is underway. It isn't unusual to see the equivalent happen in software.
2) The "Mythical Man Month" presents a pretty good argument about fundamental complexity Vs. accidental complexity. It would be a good thing to think about.
3) Because everyone has a passing familiarity with the physical world things that aren't right get pointed out fairly quickly. In my experience is that about 20-30% of programmers can cut through the symptoms and treat the cause. Everybody else goes around plastering over cracks instead of realizing that the foundation is crumbling.
My two cents.
A vast majority of the performance gains to be had from stored procedure programming comes from two sources -- precompilation and elimination of network round trips.
Neither of these options are precluded by a correct abstract interface.
There's no doubt that such an abstract interface would hurt performance, but I would venture to say that you would give back much less than 1% of the stored procedure benefits by doing this. You can do a large number of JNI-Like calls in the ~8ms required to complete a network round trip. Add compilation and query optimization and you have a large number Vs. a very small number.
To be able to provide a migration path for both sers of MS SQL Server/Sybase, Oracle, and DB/2 seems compelling even though and such migration path is likely to be an 80/20 proposition.
Not a bad idea, in my view.
I've had to reboot my cable modem recently every night to restore connectivity. My ISP just sent out an email saying the CISCO cable modem that I'm using hammered by Code Red.
Here's the quote "With the Cisco 67x series, as well as HP print servers, 3Com switches, and almost all other embedded web server applications, the worm causes a buffer overrun which causes the device to lock up."
Is this really true? It seems pretty unlikely that almost all embedded web server application have a buffer overrun. It seems possible that a few devices do.
Anybody have more info?
I haven't used Windows XP but I have a question since you seem to have some experience with it.
Will Microsoft really send program crashdumps for non-Microsoft programs? If transmission of the equivelant of core dumps to Microsoft is something that the application developer can't control, there's a real problem.
Let's assume that I'm working for an independent software vendor and someone in the QA department makes a mistake and presses the wrong button. Boom, MS has a memory image of our new super secret software system.
That's a bad thing. Please tell me hat MS hasn't done this.
I already know people who are refusing to use XP (Windows or Office) because of the activation issues. These are people who spend a lot of time in Singapore and fly with *EVERY* CD, Serial number, CD-KEY -- Literally everything that they need to rebuild the machine. About once a year they have a problem and rebuild the machine -- they don't carry this stuff just in case.
Since these are software development types, this bit of news will even go down less well.
You get "Understanding Computers and Cognition" by Winograd and Flores.
It would save a tremendous amount of misery, frustration, and taxpayer money if this were required reading.
Small cheap and powerful. Good attributes for books and computers alike.
Me: Slashdot.org
Chatbot: A deeper algorithm is needed to respond to that correctly.
Passing the Turing test it is not but it is surprisingly insightful.