Why are you using TCP for a chat server? You could just use UDP with a single server socket, and all your objections go out the window. Sure, you lose the reliability that TCP provides, but this is a chat server--is it really a big deal if you lose the odd message?
This particular chat server was part of a gaming service that the people I was working for were developing. You had chat rooms where people could meet, and challenge each other to games. Say you challenged me to a game of chess and I accepted. The server would make a private channel for us, our client software would launch the chess client on each of our systems, and the chess clients would communicate via hidden messages in our private channel, while we could chat or trash talk with each other in that channel. If this game was for the ladder system, the score keeper application on one of our servers would join the private channel and monitor and record the moves, and update the ladder based on the result.
It's kind of bad to just a lose a move in chess, so yes, it would be a big deal to lose a message.
Hence, with the UDP approach, you just end up in your server code (and in the client code you give your users!) having to implement a retry mechanism. You'll probably need flow control, too. Bottom line is you will end up essentially implementing TCP on top of UDP
Seems kind of a waste when the Linux kernel on the server and the Windows kernel on the client already have perfectly fine TCP implementations.
I did consider it. I looked around to see if I could find an open source, application level, "TCP over UDP" hack, but couldn't find any (this was several years ago). A very cursory search just now found one that isn't production level yet.
Sockets are very annoying when you have a lot of clients being served by one server. Consider, for instance, a chat server, with 25000 clients connected. You have 25000 sockets, one per client (plus a listen socket for new clients to connect to).
Whenever data arrives, the system has to somehow notify you that one of your sockets is ready to read. That generally involves some kind of polling, with select or poll, or some kind of interrupt mechanism, such as a signal. I'm leaving out some options, but regardless of how you get notified, you then read the data from the appropriate socket.
Then guess what happens? Most likely you take that data, wrap it in a data structure that tells you which client it was for, and stick it on a work queue, where the main thread or threads pull things to process.
Step back and look at what happened here:
The data from all 25000 clients comes in on a single interface.
The kernel goes to great effort to process this stream of data and split it up into separate streams for the 25000 clients.
You have to deal with that data coming into your server application via 25000 different sockets.
You put it all back into a single stream (your work queue) as a bunch of messages.
You pull the items from the work queue to process.
That's just insane! The kernel demultiplexed the incoming data, and the server just remultiplexed it when it put it onto the work queue. Demultiplexing belongs in the server application, not the kernel.
What I want is a single stream between my code and the kernel that delivers all the data for all 25000 clients. Whenever any client has data, I want to be able to read from that, and get back a message, that identifies which client it is from, and gives me that data.
The kernel should just be parsing the incoming TCP stream enough to recognize what port a given packet is for, and what client it came from, and then should queue it up into a single stream for the server handling that port. (The kernel has enough information from that to keep track, on a per client basis, of how much data is pending in the queue for the server app, so has what it needs to manage flow control).
Because any obligation they have is to the guy who BOUGHT it from them.
I've had a dell laptop stolen. I would certainly expect them to try and check anything that they support is legit.
But he's not asking for support. He's asking to buy a part.
I don't see why a laptop should be any different than, say, a car or television in this regard. Neither my car company nor my TV company requires me to prove that I own my car or TV before selling me parts. In fact, they don't even require me to have a car or TV.
The Best Early Rogue Player in the World
on
A History of Rogue
·
· Score: 4, Interesting
The first version of Rogue that was widely circulated became quite a time sink for a lot of people at Caltech. This version was considerably harder than subsequent versions. It was extremely rare for anyone to actually win the game, by getting down deep, getting the Amulet of Yendor, and making it out alive.
One undergraduate, however, had no trouble beating it. Within a couple days of his starting playing, he had all the spots on the top score list, and all of them were total winners.
He then stopped playing, except when anyone else dared to take a spot on the top score list. Then he'd come to computing center, sit down, and 30 minutes later, the interloper would be pushed off the list.
Naturally, we all wondered how the hell this guy was so much better than the rest of us (and, based on what our contacts at other schools told us, better than anyone at their schools, too). He didn't do anything to hide when playing--he didn't play in an office with a private terminal. He played right out in the main terminal room, where anyone who wanted could stand behind and watch.
As far as anyone could see, he didn't do anything significantly different than the rest of us, other than he died a lot less than we did.
Finally, he told us the secret, and we all learned an important lesson. There was no big secret--he just made every little decision correctly. For example, if he had to explore a dark room, he did it in the minimum number of steps necessary. The rest of us would use the "run until you hit something" funciton and sweep the room, which made us step on more locations, which made us have a higher chance of springing a trap.
Traps usually weren't fatal. They just put you down a few hit points for a little while. But in that little while, a monster that he would barely survive, we would barely lose to.
After he got the Amulet and was on the way up, he would only step on locations he'd already stepped on while descending, and so he NEVER sprang a trap on the way up.
He knew the odds of everything (based on observation while playing, not based on looking at the code), and would use potions or scrolls at the time when they had the maximum expected utility.
He did this for EVERY decision point in the game. He made the decision that, based on all the data available at the time, was the best decision.
None of the things I listed above, or any of the other things he did perfectly that the rest of us only did 99% perfectly would make a noticeable difference by themselves. But put them all together, and all our tiny mistakes added up to losing for us, and the lack of any mistakes added up to winning for him.
you have someone who made enough money not to have to work again during the non compete period- otherwise what the hell are you supposed to do, work at burger king?
You get a job that uses your skills in a way that doesn't compete with your previous employer. For example, when I left a job as a Unix kernel programmer, I took a job writing writing firmware for SCSI controllers and motherboards. Pretty much the same skills, but not in competition with my old job.
I've played a fair number of FPS games based on "realistic" wars (as opposed to science fiction or horror genre wars). The one thing every single one of them has in common is that it takes several respawns for me to make it through the game--or even through the first area.
This does not make me want to go out and fight in a real war. Real war does not have respawns.
Google for "definition of mathematical proof" (without the quotes). The #1 hit usually is a link to the site of a well-known usenet kook who thinks he's proved FLT, disproved the Rieman Hypothesis, proved P=NP, can factor numbers in constant time, and has found a contradiction in Galois theory (this is just a partial list of his accomplishments), and is being suppressed by a world wide conspiracy of mathematicians--whom he is soon going to take down by destroying the University system so they all lose tenure. He also suspects that many top mathematicians may be aliens (from space), trying to destroy humanity.
I don't have access to WolframAlpha, so have no idea what it would answer for "definition of mathematical proof", but I'd bet a large amount that it will not give a link to the aforementioned kook site.
Google is a web search engine. It's job, which it does very well, is to index the web, and to find sites that appear relevant to a query, and then rank those based on how important they appear to be judged by what other sites reference them. The users of the web find crackpots more interesting than mathematicians, so kook math sites rank high.
WolframAlpha is not a web search engine. It's job is to work with a large database of data that was collected and vetted by people for accuracy, and use that database to derive answers to questions.
You can't meaningfully compare Google and WolframAlpha, because what they are meant to do is so different.
What I don't understand about *BSD is why it isn't getting the kind of uptake in embedded systems that Linux is. It's technically as good, and comes with a lot less licensing risk. There is a lot less variation in interpretation of the BSD license than there is of GPL.
You don't run the risk of obeying, but still getting massively bitched at for not obeying the "spirit" of the license (think Tivo).
You don't have to worry with BSD about exactly how the code you wrote interfaces to the BSD code--no metaphysical discussion over whether a dynamically loaded kernel module is different from a dynamically loaded user space application from a licensing point of view.
No issues with using BSD code in a device that requires a subscription to work. According to the FSF, you can't use GPL code in a device that requires a subscription to operate. That raises some alarms for Linux use in cell phones, and in cable boxes and DVRs that are tied to specific cable or satellite companies.
I would expect the above risks, and others I haven't listed, even if in some cases remote, would be scary enough to the cell phone companies, the set-top box makers, the router makers, and so on, to create quite a bit of demand for an embedded *BSD.
The current spec doesn't cover spreadsheet formulas: it has a big whole and basically says "Do what OpenOffice.org does for now".
It's even worse than that, because what OpenOffice does is reverse engineer Excel and try to match that. Ironically, the best reference you can get right now to what the functions in OpenOffice do (aside from reading the source code) is the OOXML spec. A large part of the 6000 pages the anti-OOXML folks kept complaining about is an extremely detailed and precise specification of spreadsheet functions and formulas. For example, some of the financial functions have up to 4 pages each giving very precise formulas for that they compute, how they handle edge cases, and things like that.
And dont forget they still have the only software that can render their format 100% correctly because of all the 'render this the way Office 97 does' legacy crap
Why is Google supposed to change its business model because Disney has a different business model?
Because Google's business model is losing a quarter of a billion dollars a year on YouTube (that's the low end of published estimates)? Because Hulu will have higher advertising revenue this year than YouTube, on much lower traffic?
I don't see why google doesn't just put some basic google text ads on the right of youtube served up based on the description of the video and the content of the comments
The big problem is that advertisers don't want their ads to show up next to videos that will offend their customers. YouTube is full of truly disgusting content, and it is almost impossible to pick keywords that will hit the places you would like your ad to be without also hitting a lot of disgusting videos.
The problem is making money. Yes, Youtube is popular, but is it profitable yet? I don't know. Advertisers won't pay much on ad space until they can place their ads on premium content, and they won't be able to get premium content until they can show that advertisers are willing to pay a premium. It's a catch 22.
Estimates vary, but most analysts put YouTube's loss to Google at between $250 million and $500 million per year, with the bulk of that being due to bandwidth costs. The big problem is almost no one wants their ads on user supplied content.
Suppose, for instance, you were a company like Purina. You are interested in advertising your cat food. If you told Google to show your ad on videos that match the keywords "cat" and "cute", sure, you'll get a lot of impressions on videos of nice cats doing cute things. And you'll also get on videos of cute cats getting run over by lawn mowers, sticking paws in garbage disposals, and so on. Purina does NOT want to be associated in any way with running cats over with lawn mowers.
One article I read, if I recall correctly, said that Hulu is already getting more advertising revenue than YouTube, despite only having a fraction of the visitors YouTable has.
However, I don't see it as that big an issue, either; Google is here to stay, so is YouTube, and if it became THE site for non-commercial content, I for one would still use it. I suspect others would, also
Google is losing over a quarter of a billion dollars a year on YouTube just from bandwidth costs. How long are they going to be willing to keep that up?
Sure, there are lots of bad ways to use frames, but in and of itself frames are not a bad thing. In fact most, if not all of the examples mentioned are specifically examples of how to use frames RIGHT. They identify themselves, give you a way to break out of it, and allow you to continue to get the "Web 2.0"/AJAXy (or whatever buzzword you want to use) services from their site while letting you to see the pages you want to see
Nope. None of them are examples of using frames right, since they break navigation and bookmarking. Go RTFA, and in the RTFA, follow the link to Jakob Nielsen's article to learn about the problem of frames that you've overlooked.
Take a look at the frame Digg is using. It has a close box on it. If you click that, the frame goes away, leaving you on the (formerly) framed page. That's the kind of thing he means by "close the frame".
Perhaps because Tom Tom's business model involves building and selling GPS devices, and not fighting patent battles?
I suppose TomTom's suits against Garmin and Toyota were filed because it gets too cold in the Netherlands and they wanted to spend some time in the Eastern District of Texas (their venue of choice when they sue others)?
When Linus was defending monolithic kernels as superior to microkernels in performance, QNX, a microkernel, was blowing the socks off Linux in pretty much every important performance metric (and doing it with much less code, and using much less memory).
Slashdot Mirror
This particular chat server was part of a gaming service that the people I was working for were developing. You had chat rooms where people could meet, and challenge each other to games. Say you challenged me to a game of chess and I accepted. The server would make a private channel for us, our client software would launch the chess client on each of our systems, and the chess clients would communicate via hidden messages in our private channel, while we could chat or trash talk with each other in that channel. If this game was for the ladder system, the score keeper application on one of our servers would join the private channel and monitor and record the moves, and update the ladder based on the result.
It's kind of bad to just a lose a move in chess, so yes, it would be a big deal to lose a message.
Hence, with the UDP approach, you just end up in your server code (and in the client code you give your users!) having to implement a retry mechanism. You'll probably need flow control, too. Bottom line is you will end up essentially implementing TCP on top of UDP
Seems kind of a waste when the Linux kernel on the server and the Windows kernel on the client already have perfectly fine TCP implementations.
I did consider it. I looked around to see if I could find an open source, application level, "TCP over UDP" hack, but couldn't find any (this was several years ago). A very cursory search just now found one that isn't production level yet.
Sockets are very annoying when you have a lot of clients being served by one server. Consider, for instance, a chat server, with 25000 clients connected. You have 25000 sockets, one per client (plus a listen socket for new clients to connect to).
Whenever data arrives, the system has to somehow notify you that one of your sockets is ready to read. That generally involves some kind of polling, with select or poll, or some kind of interrupt mechanism, such as a signal. I'm leaving out some options, but regardless of how you get notified, you then read the data from the appropriate socket.
Then guess what happens? Most likely you take that data, wrap it in a data structure that tells you which client it was for, and stick it on a work queue, where the main thread or threads pull things to process.
Step back and look at what happened here:
That's just insane! The kernel demultiplexed the incoming data, and the server just remultiplexed it when it put it onto the work queue. Demultiplexing belongs in the server application, not the kernel.
What I want is a single stream between my code and the kernel that delivers all the data for all 25000 clients. Whenever any client has data, I want to be able to read from that, and get back a message, that identifies which client it is from, and gives me that data.
The kernel should just be parsing the incoming TCP stream enough to recognize what port a given packet is for, and what client it came from, and then should queue it up into a single stream for the server handling that port. (The kernel has enough information from that to keep track, on a per client basis, of how much data is pending in the queue for the server app, so has what it needs to manage flow control).
But he's not asking for support. He's asking to buy a part.
I don't see why a laptop should be any different than, say, a car or television in this regard. Neither my car company nor my TV company requires me to prove that I own my car or TV before selling me parts. In fact, they don't even require me to have a car or TV.
What business is it of theirs if he bought it or stole it?
How many laptops have you built?
The first version of Rogue that was widely circulated became quite a time sink for a lot of people at Caltech. This version was considerably harder than subsequent versions. It was extremely rare for anyone to actually win the game, by getting down deep, getting the Amulet of Yendor, and making it out alive.
One undergraduate, however, had no trouble beating it. Within a couple days of his starting playing, he had all the spots on the top score list, and all of them were total winners.
He then stopped playing, except when anyone else dared to take a spot on the top score list. Then he'd come to computing center, sit down, and 30 minutes later, the interloper would be pushed off the list.
Naturally, we all wondered how the hell this guy was so much better than the rest of us (and, based on what our contacts at other schools told us, better than anyone at their schools, too). He didn't do anything to hide when playing--he didn't play in an office with a private terminal. He played right out in the main terminal room, where anyone who wanted could stand behind and watch.
As far as anyone could see, he didn't do anything significantly different than the rest of us, other than he died a lot less than we did.
Finally, he told us the secret, and we all learned an important lesson. There was no big secret--he just made every little decision correctly. For example, if he had to explore a dark room, he did it in the minimum number of steps necessary. The rest of us would use the "run until you hit something" funciton and sweep the room, which made us step on more locations, which made us have a higher chance of springing a trap.
Traps usually weren't fatal. They just put you down a few hit points for a little while. But in that little while, a monster that he would barely survive, we would barely lose to.
After he got the Amulet and was on the way up, he would only step on locations he'd already stepped on while descending, and so he NEVER sprang a trap on the way up.
He knew the odds of everything (based on observation while playing, not based on looking at the code), and would use potions or scrolls at the time when they had the maximum expected utility.
He did this for EVERY decision point in the game. He made the decision that, based on all the data available at the time, was the best decision.
None of the things I listed above, or any of the other things he did perfectly that the rest of us only did 99% perfectly would make a noticeable difference by themselves. But put them all together, and all our tiny mistakes added up to losing for us, and the lack of any mistakes added up to winning for him.
You get a job that uses your skills in a way that doesn't compete with your previous employer. For example, when I left a job as a Unix kernel programmer, I took a job writing writing firmware for SCSI controllers and motherboards. Pretty much the same skills, but not in competition with my old job.
I've played a fair number of FPS games based on "realistic" wars (as opposed to science fiction or horror genre wars). The one thing every single one of them has in common is that it takes several respawns for me to make it through the game--or even through the first area.
This does not make me want to go out and fight in a real war. Real war does not have respawns.
Google for "definition of mathematical proof" (without the quotes). The #1 hit usually is a link to the site of a well-known usenet kook who thinks he's proved FLT, disproved the Rieman Hypothesis, proved P=NP, can factor numbers in constant time, and has found a contradiction in Galois theory (this is just a partial list of his accomplishments), and is being suppressed by a world wide conspiracy of mathematicians--whom he is soon going to take down by destroying the University system so they all lose tenure. He also suspects that many top mathematicians may be aliens (from space), trying to destroy humanity.
I don't have access to WolframAlpha, so have no idea what it would answer for "definition of mathematical proof", but I'd bet a large amount that it will not give a link to the aforementioned kook site.
Google is a web search engine. It's job, which it does very well, is to index the web, and to find sites that appear relevant to a query, and then rank those based on how important they appear to be judged by what other sites reference them. The users of the web find crackpots more interesting than mathematicians, so kook math sites rank high.
WolframAlpha is not a web search engine. It's job is to work with a large database of data that was collected and vetted by people for accuracy, and use that database to derive answers to questions.
You can't meaningfully compare Google and WolframAlpha, because what they are meant to do is so different.
What I don't understand about *BSD is why it isn't getting the kind of uptake in embedded systems that Linux is. It's technically as good, and comes with a lot less licensing risk. There is a lot less variation in interpretation of the BSD license than there is of GPL.
You don't run the risk of obeying, but still getting massively bitched at for not obeying the "spirit" of the license (think Tivo).
You don't have to worry with BSD about exactly how the code you wrote interfaces to the BSD code--no metaphysical discussion over whether a dynamically loaded kernel module is different from a dynamically loaded user space application from a licensing point of view.
No issues with using BSD code in a device that requires a subscription to work. According to the FSF, you can't use GPL code in a device that requires a subscription to operate. That raises some alarms for Linux use in cell phones, and in cable boxes and DVRs that are tied to specific cable or satellite companies.
I would expect the above risks, and others I haven't listed, even if in some cases remote, would be scary enough to the cell phone companies, the set-top box makers, the router makers, and so on, to create quite a bit of demand for an embedded *BSD.
It's even worse than that, because what OpenOffice does is reverse engineer Excel and try to match that. Ironically, the best reference you can get right now to what the functions in OpenOffice do (aside from reading the source code) is the OOXML spec. A large part of the 6000 pages the anti-OOXML folks kept complaining about is an extremely detailed and precise specification of spreadsheet functions and formulas. For example, some of the financial functions have up to 4 pages each giving very precise formulas for that they compute, how they handle edge cases, and things like that.
Someone has to pay the bandwidth costs. That "free" content on Google is costing them over a quarter of a billion dollars a year in bandwidth cost.
Bittorrent uses even more bandwidth, so shifting to bittorrent isn't the answer--it just shifts who ends up eating the costs.
Bullshit, Twitter.
Because Google's business model is losing a quarter of a billion dollars a year on YouTube (that's the low end of published estimates)? Because Hulu will have higher advertising revenue this year than YouTube, on much lower traffic?
The big problem is that advertisers don't want their ads to show up next to videos that will offend their customers. YouTube is full of truly disgusting content, and it is almost impossible to pick keywords that will hit the places you would like your ad to be without also hitting a lot of disgusting videos.
Estimates vary, but most analysts put YouTube's loss to Google at between $250 million and $500 million per year, with the bulk of that being due to bandwidth costs. The big problem is almost no one wants their ads on user supplied content.
Suppose, for instance, you were a company like Purina. You are interested in advertising your cat food. If you told Google to show your ad on videos that match the keywords "cat" and "cute", sure, you'll get a lot of impressions on videos of nice cats doing cute things. And you'll also get on videos of cute cats getting run over by lawn mowers, sticking paws in garbage disposals, and so on. Purina does NOT want to be associated in any way with running cats over with lawn mowers.
One article I read, if I recall correctly, said that Hulu is already getting more advertising revenue than YouTube, despite only having a fraction of the visitors YouTable has.
Google is losing over a quarter of a billion dollars a year on YouTube just from bandwidth costs. How long are they going to be willing to keep that up?
Nope. None of them are examples of using frames right, since they break navigation and bookmarking. Go RTFA, and in the RTFA, follow the link to Jakob Nielsen's article to learn about the problem of frames that you've overlooked.
Take a look at the frame Digg is using. It has a close box on it. If you click that, the frame goes away, leaving you on the (formerly) framed page. That's the kind of thing he means by "close the frame".
Why don't you run the OS X version of Cinepaint, available from their sourceforge page?
That would be an insightful post--if we lived in a world where programmers did not need to eat.
I suppose TomTom's suits against Garmin and Toyota were filed because it gets too cold in the Netherlands and they wanted to spend some time in the Eastern District of Texas (their venue of choice when they sue others)?
When Linus was defending monolithic kernels as superior to microkernels in performance, QNX, a microkernel, was blowing the socks off Linux in pretty much every important performance metric (and doing it with much less code, and using much less memory).
Wrong. Do you even know what a microkernel is?
It was a teaching tool 22 years ago, when it was created. It has undergone a lot of changes since then.