Dick Bentley's railbike is pretty neat. I visited him a couple of years ago, and he took me for a ride down the railroad on them. Once you get over the fear of falling off (which doesn't happen), they're great. -russ
Sigh. You don't get it, do you? You suggest different protocols, when TCP works just fine. The reason you want to stay with TCP is because of the infinite number of ways people have implemented TCP. Just as one HUGE example, consider all the people behind NAT. How are you going to "distribute asynchronous update notifications"?
I'd like to hear one person, just one person say "Hmmm.... I wonder why Russ didn't suggest asynchronous update notifications?" And then maybe go on to answer themselves by saying "Oh! I get it! Russ is right! Hey, that's a great idea! It's backwards compatible and yet does exactly what is needed to turn RSS into a packet-efficient protocol."
Instead, you get weenies who say something slightly more erudite than "duh" but which could be summarized thusly. You also get people (stand up and take a bow, Salamander) who say "Geez, that idea has OBVIOUS PROBLEMS" even though I obviously anticipate those OBVIOUS PROBLEMS and suggest a solution. Honestly, I see why people have such a low opinion of slashdot posters. Yer all a bunch of dummies! -russ p.s. pant, pant, pant, pant, okay, I feel better now.
Clearly they haven't, given the replies to the main story and to my posting. AC: "Hey RSS should have a schedule for updates!" Russ: "Yeah! Just like the DNS!" -russ
Honest to goodness, I wish idiots would do a little googling before they resorted to ad-hominem argumentation. At least know something about the person you're arguing against. -russ p.s. I'm not suggesting that anybody should break standard TCP. TCP the protocol is perfectly fine. TCP the implementations typically cannot hold millions of connections open.
What I suggest is not reimplementing everybody's TCP stack! Just the people who are publishing extremely popular RSS feeds. Mine is a much simpler solution than yours because it continues to rely on TCP, and doesn't create a new protocol. -russ
I'm not suggesting that users need to do anything special. The solution to the "people are hitting my web server for RSS feeds every ten minutes, or every hour on the hour" can be solved on a level much lower than the user level. -russ p.s. effing get it?
No, it's not necessary to add scheduling. All that's needed is better TCP stacks which can handle millions of concurrent open connections. Presumably this would happen in a database in userland, and not in the kernel. -russ
Several people have pointed out that you want a schedule. No, you don't. That just foments the stampeding herd of clients. You really want to allow people to connect whenever they want, and then receive data only when you're ready and able to send it back.
Basically, you use the TCP connection as a subscription. Call it "repeated confirmation of opt-in" if you want. Every time the user re-connects to get the next update (which they will probably do immediately; may as well) that's an indication that they want another copy. Everybody gets updates as soon as possible, just like email, only it's not possible to force data on everybody, as we've seen happen with email.
RSS just needs better TCP stacks. Here's how it would work: when your RSS client connects to an RSS server, it would simply leave the connection open until the next time the RSS data got updated. Then you would receive a copy of the RSS content. You simply *couldn't* fetch data that hadn't been updated.
The reason this needs better TCP stacks is because every open connection is stored in kernel memory. That's not necessary. Once you have the connecting ip, port, and sequence number, those should go into a database, to be pulled out later when the content has been updated. -russ
Are the levels going to be the same, and will I still be able to get a map by hitting Tab? If so, I might buy a new computer just to play the game just to relive the original DOOM experience. -russ
I built one of these back 1978. Yes, virginia, they had etch-a-sketches back then. And stepping motors. Yes, and even personal computers. I remember when we added 4KB of RAM, for a total of 24K! You could do anything in 24K! Mu-hahahahahaha! -russ
GRASS can *do* all that stuff. It's just that ordinary mortals can't get GRASS to do it. The basic code underneath GRASS seems to be perfectly functional. It just needs to had a good user interface written from scratch, and then have the various GRASS mechanisms put underneath it. -russ
Why should you pay taxes for development of public (free/open source) software? Fund your project through the Public Software Fund, and everyone who contributes gets to deduce their contribution from the US taxes. -russ
I want to add that you reflect a profound misapprehension of what economists do. Economists don't tell you what to do. They tell you what people will do in response to your actions. So, for example, economists will tell you that if you raise the minimum wage, you will cause the workers whose labor is least in demand to become unemployed. Those workers might be lazy, stupid, unskilled, or niggers, or any combination of the above. It's up to you to decide whether you want higher wages and higher unemployment, or full employment. There is no "should" in economics, just as there is no "should" in physics. -russ
Obviously, I disagree. Economics (or at least good economics) is ordained and unchangable. For example, you'll often hear Friends of the FCUN flavor say "Oh, we must think seven generations ahead." That's bullshit. People don't behave that way, and I proved it to them (not that they were paying attention). I said, at an FCUN talk some years ago "I'll donate five dollars now, or twenty dollars five years from now. Which do you want?" They demonstrated their human short-sightedness by asking for the five dollars now. -russ
You write that as if you were being profound. Instead, you are being foolish. Change economics to physics and you will see that you sound like a flat-earther. Look around! The earth is obviously not flat. And the socialism that most Friends preach works only on flat earths. -russ
Slashdot Mirror
RUF is a better dual-mode system. It uses a triangular guideway and works with specially-designed cars, busses, and small goods deliveries.
-russ
Dick Bentley's railbike is pretty neat. I visited him a couple of years ago, and he took me for a ride down the railroad on them. Once you get over the fear of falling off (which doesn't happen), they're great.
-russ
No, and I'll thank you to call me Sir Nelson. A little in advance my knighthood, but practice wouldn't hurt.
-russ
Sigh. You don't get it, do you? You suggest different protocols, when TCP works just fine. The reason you want to stay with TCP is because of the infinite number of ways people have implemented TCP. Just as one HUGE example, consider all the people behind NAT. How are you going to "distribute asynchronous update notifications"?
I'd like to hear one person, just one person say "Hmmm.... I wonder why Russ didn't suggest asynchronous update notifications?" And then maybe go on to answer themselves by saying "Oh! I get it! Russ is right! Hey, that's a great idea! It's backwards compatible and yet does exactly what is needed to turn RSS into a packet-efficient protocol."
Instead, you get weenies who say something slightly more erudite than "duh" but which could be summarized thusly. You also get people (stand up and take a bow, Salamander) who say "Geez, that idea has OBVIOUS PROBLEMS" even though I obviously anticipate those OBVIOUS PROBLEMS and suggest a solution. Honestly, I see why people have such a low opinion of slashdot posters. Yer all a bunch of dummies!
-russ
p.s. pant, pant, pant, pant, okay, I feel better now.
Clearly they haven't, given the replies to the main story and to my posting. AC: "Hey RSS should have a schedule for updates!" Russ: "Yeah! Just like the DNS!"
-russ
No. DNS TTLs.
Now do you understand why my suggestion is better? Or must I explain it in greater detail?
-russ
Try this:
/proc/sys/fs/file-max
echo 1000000 >
and then see if your Linux box can handle a million simultaneous TCP connections. When you have rebooted your machine, you will be enlightened.
Please read the subject that you posted this under. Did I say "RSS needs better TCP"? Or did I say "RSS needs better TCP stacks".
I'd be happy to reply in detail once we're talking about the same thing.
-russ
Honest to goodness, I wish idiots would do a little googling before they resorted to ad-hominem argumentation. At least know something about the person you're arguing against.
-russ
p.s. I'm not suggesting that anybody should break standard TCP. TCP the protocol is perfectly fine. TCP the implementations typically cannot hold millions of connections open.
Dude, go google for "russ" if you think I'm some sort of newbie non-anonymous non-coward.
-russ
What I suggest is not reimplementing everybody's TCP stack! Just the people who are publishing extremely popular RSS feeds. Mine is a much simpler solution than yours because it continues to rely on TCP, and doesn't create a new protocol.
-russ
I'm not suggesting that users need to do anything special. The solution to the "people are hitting my web server for RSS feeds every ten minutes, or every hour on the hour" can be solved on a level much lower than the user level.
-russ
p.s. effing get it?
I'm not sure you understand the problem. Try compiling your kernel to support a million persistent connections.
-russ
No, it's not necessary to add scheduling. All that's needed is better TCP stacks which can handle millions of concurrent open connections. Presumably this would happen in a database in userland, and not in the kernel.
-russ
Several people have pointed out that you want a schedule. No, you don't. That just foments the stampeding herd of clients. You really want to allow people to connect whenever they want, and then receive data only when you're ready and able to send it back.
Basically, you use the TCP connection as a subscription. Call it "repeated confirmation of opt-in" if you want. Every time the user re-connects to get the next update (which they will probably do immediately; may as well) that's an indication that they want another copy. Everybody gets updates as soon as possible, just like email, only it's not possible to force data on everybody, as we've seen happen with email.
RSS just needs better TCP stacks. Here's how it would work: when your RSS client connects to an RSS server, it would simply leave the connection open until the next time the RSS data got updated. Then you would receive a copy of the RSS content. You simply *couldn't* fetch data that hadn't been updated.
The reason this needs better TCP stacks is because every open connection is stored in kernel memory. That's not necessary. Once you have the connecting ip, port, and sequence number, those should go into a database, to be pulled out later when the content has been updated.
-russ
Are the levels going to be the same, and will I still be able to get a map by hitting Tab? If so, I might buy a new computer just to play the game just to relive the original DOOM experience.
-russ
I built one of these back 1978. Yes, virginia, they had etch-a-sketches back then. And stepping motors. Yes, and even personal computers. I remember when we added 4KB of RAM, for a total of 24K! You could do anything in 24K! Mu-hahahahahaha!
-russ
.pdf, not .doc, nor .sxi.
-russ
GRASS can *do* all that stuff. It's just that ordinary mortals can't get GRASS to do it. The basic code underneath GRASS seems to be perfectly functional. It just needs to had a good user interface written from scratch, and then have the various GRASS mechanisms put underneath it.
-russ
Why should you pay taxes for development of public (free/open source) software? Fund your project through the Public Software Fund, and everyone who contributes gets to deduce their contribution from the US taxes.
-russ
I want to add that you reflect a profound misapprehension of what economists do. Economists don't tell you what to do. They tell you what people will do in response to your actions. So, for example, economists will tell you that if you raise the minimum wage, you will cause the workers whose labor is least in demand to become unemployed. Those workers might be lazy, stupid, unskilled, or niggers, or any combination of the above. It's up to you to decide whether you want higher wages and higher unemployment, or full employment. There is no "should" in economics, just as there is no "should" in physics.
-russ
Obviously, I disagree. Economics (or at least good economics) is ordained and unchangable. For example, you'll often hear Friends of the FCUN flavor say "Oh, we must think seven generations ahead." That's bullshit. People don't behave that way, and I proved it to them (not that they were paying attention). I said, at an FCUN talk some years ago "I'll donate five dollars now, or twenty dollars five years from now. Which do you want?" They demonstrated their human short-sightedness by asking for the five dollars now.
-russ
You write that as if you were being profound. Instead, you are being foolish. Change economics to physics and you will see that you sound like a flat-earther. Look around! The earth is obviously not flat. And the socialism that most Friends preach works only on flat earths.
-russ
I see that you cannot be convinced by facts. That is fine, but I think most people will say that you lost this argument.
-russ