The order site still says 12 weeks delivery time. Obviously the manufacturing ramp up is not keeping up with orders. Maybe removing the order limit is still a bad idea. Maybe just raising it to a few (schools can order more) would be better.
It's more than just caching, these days. It's also about sending the requests to the appropriate server. For example, if you can send the requests of a logged in user to the same server or group of servers, it's easier to manage session state (each of 10000 servers holding 400 session states, instead of 10000 servers having to access a centralized store of 4000000 session states).
One thing a new protocol could do to better manage that is, after session authentication, tell the client another IP address and/or port to use so that subsequent requests go to a session group partition, which better distributes the load without having so large a gauntlet of layer 4+ smart session routers.
Or better yet, just hold the session up for as long as the user is present and using the service. First, think VNC. Then think replacing VNC with something smart.
XML is for marking up documents. Our problem with HTTP is that it is stuck in the legacy document model. Today we need streams, and optimization of sessions. XML would just be the markup of documents we might want to choose to fetch over those streams. Notice that audio/video/media containers are not based on XML, and never should be.
That's what you get when someone designs a protocol and then someone ELSE decides to change it in different ways of thinking. If the first one was well designed, changes should end up looking like they were part of the original. If the first one was poorly designed, make a whole new one.
SCTP sessions give you multiple streams to do anything you want in them. And once you have encryption established in stream 0, a simple key exchange is all that is needed encrypt the other streams. You can do fetches in some streams while others are doing interactive audio/video streaming. And that's all done within one session as the network stack, and session routers, see it.
XML is for marking up documents, not serializing data structures.
Now suppose we make HTTP based on XML. During the HTTP header parse, we need the schema. Fetch it. With what? With HTTP. Now we need to parse more XML and need another schema we have to get with HTTP which then has to be parsed...
XML is not for protocols. JSON is at least more usable. Some simpler formats exist, too.
And what do you do when something does not validate? Kick the guy who typed it in manually? Oh wait, what if it was generated by a program?
The whole schema thing in XML is one of the things that makes it suck. Just write the data correctly in the first place and discard anything that doesn't make sense to the application.
Much of what the web has become is no longer fitting the "fetch a document" model that HTTP (and GOPHER before it) are designed to do. This is why we have hacks like cookie managed sessions. We are effectively treating the document as a fat UDP datagram. The replacement... and I do mean replacement, for HTTP, should integrate the session management with it, among other things. The replacement needs to hold the TCP connection (or better, the SCTP session), in place as a matter of course, integrated into the design, instead of patched around as HTTP does now. With SCTP, each stream can manage its own start and end, with a simpler encryption startup based on encrypted session management on stream 0. Then you can have multiple streams for a variety of serviced functions from nailed up streams for continuous audio/video, to streams used on the fly for document fetch. No chunking is needed since it's all done in SCTP.
We can let our computers connect into a central cloud management system and provide cloud service instances to the government when their national security is more important than us using computers... the CROWD CLOUD. Yeah, that will work just fine.
Those who think Viacom is worth 30% more can continue their subscription to those channels. Those who don't can quit. It's time to end the table d'hôte channel lineup.
Or it could be that there are enough C programmers around that it's not necessary to advertise for jobs. Only about 10 to 15 of open positions ever get listed on the big job boards. And those are the ones where management (or in some cases HR) stuck in too many requirements that make it hard to find people (maybe because they only want top one percent rock star programmers).
And that one requirement of programming in C makes for a fine barrier to select for to programming talent that can get the job done, reducing the need for hiring extra grunt programmers.
I just ran across a company that does almost all their in-house development in C. They are not hiring. They have no trouble finding C programmers when they need more, and those they have are very productive.
Indeed there was OO before C++. I first learned it in a language called CLU. But the language itself was not really mature. I just took the object abstraction idea back to assembly language when I abandoned CLU.
Can you tell, from just watching an office make an arrest, whether he/she is one that is one of the few bad apples? But I know they are there because I've had the opportunity to deal with a couple of them on a longer term basis that clearly to me were among the bad apples. But they didn't do that all the time.
I suspect you can't figure out on first meeting, either. Don't expect the public can. So many in the public will have latent suspicion all the time. "Is he, or isn't he".
The dark clothing should not cause suspicion. A backpack should not cause suspicion. Walking around a residential neighborhood at 3 AM, maybe. Crouch behind a car when you pass by, for sure.
As to the issuing videoing cops doing their job, it should be taken by the vast majority of cops that are good as an opportunity to show how they are making the neighborhood safer. I see no issuing with someone videoing everything cops do, unless they are getting in the way or shouting remarks, or something. Then it should be a matter just the same even if they had no camera.
The corporations are right now afraid of doing things for various reasons. But they are still working towards that, through plans to try to deploy in-house stuff with a deliver advantage, and through lobbying, bribery, and corruption with Congress, and hoping to see Romney and his crew win in November (Obama and his crew are not much better). The government screwovers are coming from both parties, often together. But that doesn't justify giving corporations a free rein (like Ron Paul would do). Things will get worse if we let them.
Slashdot Mirror
The order site still says 12 weeks delivery time. Obviously the manufacturing ramp up is not keeping up with orders. Maybe removing the order limit is still a bad idea. Maybe just raising it to a few (schools can order more) would be better.
Just don't hire them as members of the military in the usual sense.
They seem to be having success in China, North Korea, and Russia.
Use them at arms length.
It's more than just caching, these days. It's also about sending the requests to the appropriate server. For example, if you can send the requests of a logged in user to the same server or group of servers, it's easier to manage session state (each of 10000 servers holding 400 session states, instead of 10000 servers having to access a centralized store of 4000000 session states).
One thing a new protocol could do to better manage that is, after session authentication, tell the client another IP address and/or port to use so that subsequent requests go to a session group partition, which better distributes the load without having so large a gauntlet of layer 4+ smart session routers.
Or better yet, just hold the session up for as long as the user is present and using the service. First, think VNC. Then think replacing VNC with something smart.
XML is for marking up documents. Our problem with HTTP is that it is stuck in the legacy document model. Today we need streams, and optimization of sessions. XML would just be the markup of documents we might want to choose to fetch over those streams. Notice that audio/video/media containers are not based on XML, and never should be.
That's what you get when someone designs a protocol and then someone ELSE decides to change it in different ways of thinking. If the first one was well designed, changes should end up looking like they were part of the original. If the first one was poorly designed, make a whole new one.
SCTP sessions give you multiple streams to do anything you want in them. And once you have encryption established in stream 0, a simple key exchange is all that is needed encrypt the other streams. You can do fetches in some streams while others are doing interactive audio/video streaming. And that's all done within one session as the network stack, and session routers, see it.
s/Cute/Ugly/
XML is for marking up documents, not serializing data structures.
Now suppose we make HTTP based on XML. During the HTTP header parse, we need the schema. Fetch it. With what? With HTTP. Now we need to parse more XML and need another schema we have to get with HTTP which then has to be parsed ...
XML is not for protocols. JSON is at least more usable. Some simpler formats exist, too.
And what do you do when something does not validate? Kick the guy who typed it in manually? Oh wait, what if it was generated by a program?
The whole schema thing in XML is one of the things that makes it suck. Just write the data correctly in the first place and discard anything that doesn't make sense to the application.
Much of what the web has become is no longer fitting the "fetch a document" model that HTTP (and GOPHER before it) are designed to do. This is why we have hacks like cookie managed sessions. We are effectively treating the document as a fat UDP datagram. The replacement ... and I do mean replacement, for HTTP, should integrate the session management with it, among other things. The replacement needs to hold the TCP connection (or better, the SCTP session), in place as a matter of course, integrated into the design, instead of patched around as HTTP does now. With SCTP, each stream can manage its own start and end, with a simpler encryption startup based on encrypted session management on stream 0. Then you can have multiple streams for a variety of serviced functions from nailed up streams for continuous audio/video, to streams used on the fly for document fetch. No chunking is needed since it's all done in SCTP.
If you substitute JSON (or something like it with equal or better simplicity) for XML, then I might go along with it.
We can let our computers connect into a central cloud management system and provide cloud service instances to the government when their national security is more important than us using computers ... the CROWD CLOUD. Yeah, that will work just fine.
They don't want to PAY for it until they actually need it.
AWS has a specific cloud area just for the government. Commercial users are not in there at all. Isn't that good enough?
And I would have posted as Anonymous Coward if I had, too.
À la carte menus FTW!
\o/
Those who think Viacom is worth 30% more can continue their subscription to those channels. Those who don't can quit. It's time to end the table d'hôte channel lineup.
It seems to make assumptions that are not valid, such as the host name being a valid RHS of email.
Or it could be that there are enough C programmers around that it's not necessary to advertise for jobs. Only about 10 to 15 of open positions ever get listed on the big job boards. And those are the ones where management (or in some cases HR) stuck in too many requirements that make it hard to find people (maybe because they only want top one percent rock star programmers).
And that one requirement of programming in C makes for a fine barrier to select for to programming talent that can get the job done, reducing the need for hiring extra grunt programmers.
I just ran across a company that does almost all their in-house development in C. They are not hiring. They have no trouble finding C programmers when they need more, and those they have are very productive.
Indeed there was OO before C++. I first learned it in a language called CLU. But the language itself was not really mature. I just took the object abstraction idea back to assembly language when I abandoned CLU.
Can you tell, from just watching an office make an arrest, whether he/she is one that is one of the few bad apples? But I know they are there because I've had the opportunity to deal with a couple of them on a longer term basis that clearly to me were among the bad apples. But they didn't do that all the time.
I suspect you can't figure out on first meeting, either. Don't expect the public can. So many in the public will have latent suspicion all the time. "Is he, or isn't he".
The dark clothing should not cause suspicion. A backpack should not cause suspicion. Walking around a residential neighborhood at 3 AM, maybe. Crouch behind a car when you pass by, for sure.
As to the issuing videoing cops doing their job, it should be taken by the vast majority of cops that are good as an opportunity to show how they are making the neighborhood safer. I see no issuing with someone videoing everything cops do, unless they are getting in the way or shouting remarks, or something. Then it should be a matter just the same even if they had no camera.
IN what way are these people agitators? Doing photography and filming is not.
Does it make the QR code labels?
The corporations are right now afraid of doing things for various reasons. But they are still working towards that, through plans to try to deploy in-house stuff with a deliver advantage, and through lobbying, bribery, and corruption with Congress, and hoping to see Romney and his crew win in November (Obama and his crew are not much better). The government screwovers are coming from both parties, often together. But that doesn't justify giving corporations a free rein (like Ron Paul would do). Things will get worse if we let them.