They will have VERY close to sea level weight at that altitude.
Don't think of weightlesness as being "away from the influence of gravity", instead think of it as being "in freefall" i.e. not resisting gravity but rather just falling with it.
Astronauts in earth orbit feel weightless, even though they are still subject to (almost) 100% of earth's gravity. Why? Because instead of resisting gravity (by standing on an immovable surface), they are just letting themselves free fall under the influence of gravity.
A circular or elliptical orbit may not obviously seem like freefall, but it is if you look at the vectors. If you superimpose centripetal acceleration (towards the center of the earth due to gravity) on top of just the right tangential translational velocity (orbital speed), you get a constantly curving path, that parallels the curvature of the earth. That's an orbit.
The reason the astronauts feel weightless and yet the baloonatics feel whightfull(?) is that the baloonatics are resisting gravity, rather than freefalling with it. If you could hypothetically accelerate the baloonatics to just the right orbital speed, in a direction tangential to the earth's curvature, they would be in orbit, and would be weightless.
.... but their posting of patented information to their website is what is being argued against.
Huh?
Incorporating IP covered by a patent into a product (without licence) is illegal. Publishing patented information is not. It's publically available anyway, it's not a trade secret.
Surely no law has been violated by the publishers of the web site. Someone who downloads the verilog and uses it illegally could be in violation of the law, but not the publisher, surely?
Re:Base 3 is best for dealing with Pi...
on
Ternary Computing
·
· Score: 1
Yeah, right! I suppose you have a bridge to sell, too?
I'm surprised nobody has mentioned this yet, but signalling with greater than two voltage levels per wire (and hence more than one simultaneous bit per wire) is already common practice in at least one area: Ethernet.
100Mbit ethernet uses 3 levels. Gigabit uses five. (Hope I got this right, I'm speaking from memory, and it's a while since I read the specs).
So, 100Mbit ethernet uses trits, and GBit ethernet uses quits?
Of course, it's really implimented with binary logic behind the scenes, and the conversion to & from multi-level logic happens right at the line trancievers.
Thanks, Jason. I just played around with the FEC Library a little, and it is really cool. I wish I had the time (and skill) to make use of it myself.
I also took a browse through the IETF documents (someone posted a link.), and learned a lot.
Do you get much feedback from users of your library? I'm curious what other projects are going on, especially open source ones that I could follow.
How much can you reveal about the content distribution project you are working on? For example, what platforms, and when it will be on the market.
How long do you think it will be until multicast becomes the mainstream delivery method for popular packages over the internet? That would obviously take generally accepted standards, widely-adopted packages, and I expect a lot of expensive Cisco upgrades! Do you forsee it any time soon?
I'm the original poster of the AskSlashdot question.
I'm no expert on network protocols. I'm not even a software guy. So some of
what follows may seem very naive. Bear with me and see if this makes sense.
Here's how I see it working.
Data Rate.
The server would send several streams at once on several channels, each one
paced for a different data rate. For example, the T1 user would pick a
different channel than the 28K modem user. Each channel endlessly repeats the
same data set, over & over.
Keeping Track.
Each datagram sent would contain an offset value that shows where it fits into
the big picture. Thus, the client knows which parts of the whole have been
received, and which ones have not. As we shall see, this helps deal with
start time synchronisation and dropped packet issues.
Start Time.
You don't even try to synchronise start times. If a client connects in the
middle, so what. It just stores the second half of the data set, then stays
on the line for the next repetition of the first half. The client knows when
it has received the whole data set, because each datagram is tagged with an
offset that shows where it fits into the big picture.
Missed Packets.
This is the hard part. If a client misses a packet because it is dropped en-
route, or for whatever reason, there are a few ways to deal with it.
The client could just wait for the next iteration of the data set, and
listen for the datagrams that fill in the blanks.
The protocol could use a UDP backchannel which allows clients to request
retransmissions of datagrams by offset. The server could keep track of which
datagrams have been requested, and periodically retransmit those datagrams
out of sequence. If there are too many, and forward progress is threatened,
the server could keep a histogram of which packet have been requested most
often, and resend the most-requested ones only -- let the others wait for the
next iteration.
My favorite approach: The protocol could get most of the data across,
and just not worry about the occasional gap. Once the client has a mostly-
complete data set, it could use a connected point-to-point protocol to fill
in the gaps. Rsync, for example, is very good at filling small gaps in
otherwise complete data sets. (True, this is point-to-point, and partially
defeats the purpose of using multicast, but since it's only used for
relatively tiny parts of the data set, the connections should be short-lived
and relatively few in number.)
Who will volunteer to re-do this study a little more rationally & post the results here?
(And while we wait for a volunteer, add your suggestions to the following list).
1. State the version of each browser used. Make reasonable effort to use up-to-date ones.
2. For startup time, configure all to initially display blank pages.
3. Include text-only browsers as well (lynx, w3, etc).
4. Use reasonably modern (but not high-end) hardware. At least, enough memory to be support all browser's footprints (i.e. no swap).
5. Separately measure & report "rendering speed" (i.e. from cache or file) and "loading speed" (i.e. with cache flushed).
6. For loading speed: State your internet connection type. Choose a lightly loaded server, at a time of day when your ISP performance is good.
7. Report the actual memory footprint.
8. Report the best unique features (e.g. built in ad-blocker, flexible cookie rejection, whatever.)
9. Report any obvious bad features (e.g. advertising, crashes, etc).
10. Try on a browser compliance test site, and report result. (I know they exist, don't know which is good, though).
Any volunteers to try this and post to Slashdot?
I'd volunteer, but I'm still employed (until Tuesday at least), so I don't have time!
When I was on an H1 (no B suffix, I think that's a new variation?), I was paid $26K/year. Not great for a an engineer with 5+ years experience. This was 1986-1989, so adjust for inflation if you wish. And it was in one of the highest cost-of-living parts of the US.
I also was constantly subjected to "visa blackmail", where my enployer could demand almost ANYTHING, under direct threat of firing me, knowing that I could not legally work in any other job and would be on the next plane out of the country.
However much some other posters minimize this problem, for me it was VERY real.
Slashdot Mirror
They will have VERY close to sea level weight at that altitude.
Don't think of weightlesness as being "away from the influence of gravity", instead think of it as being "in freefall" i.e. not resisting gravity but rather just falling with it.
Astronauts in earth orbit feel weightless, even though they are still subject to (almost) 100% of earth's gravity. Why? Because instead of resisting gravity (by standing on an immovable surface), they are just letting themselves free fall under the influence of gravity.
A circular or elliptical orbit may not obviously seem like freefall, but it is if you look at the vectors. If you superimpose centripetal acceleration (towards the center of the earth due to gravity) on top of just the right tangential translational velocity (orbital speed), you get a constantly curving path, that parallels the curvature of the earth. That's an orbit.
The reason the astronauts feel weightless and yet the baloonatics feel whightfull(?) is that the baloonatics are resisting gravity, rather than freefalling with it. If you could hypothetically accelerate the baloonatics to just the right orbital speed, in a direction tangential to the earth's curvature, they would be in orbit, and would be weightless.
For every 1 kilo of Hydrogen you burn, you need 8 kilos of Oxygen. Where do you get it?
You can't carry it as payload, obviously, because when you multiply the weight by 9 you no longer have a lighter-than-air craft.
So, you have to rely on ambient oxygen. And there just isn't enough at that altitude.
Nice idea, though. Pity about those pesky laws of physics.
.... but their posting of patented information to their website is what is being argued against.
Huh?
Incorporating IP covered by a patent into a product (without licence) is illegal. Publishing patented information is not. It's publically available anyway, it's not a trade secret.
Surely no law has been violated by the publishers of the web site. Someone who downloads the verilog and uses it illegally could be in violation of the law, but not the publisher, surely?
Yeah, right! I suppose you have a bridge to sell, too?
I'm surprised nobody has mentioned this yet, but signalling with greater than two voltage levels per wire (and hence more than one simultaneous bit per wire) is already common practice in at least one area: Ethernet.
100Mbit ethernet uses 3 levels. Gigabit uses five. (Hope I got this right, I'm speaking from memory, and it's a while since I read the specs).
So, 100Mbit ethernet uses trits, and GBit ethernet uses quits?
Of course, it's really implimented with binary logic behind the scenes, and the conversion to & from multi-level logic happens right at the line trancievers.
Thanks, Jason. I just played around with the FEC Library a little, and it is really cool. I wish I had the time (and skill) to make use of it myself. I also took a browse through the IETF documents (someone posted a link.), and learned a lot.
Do you get much feedback from users of your library? I'm curious what other projects are going on, especially open source ones that I could follow. How much can you reveal about the content distribution project you are working on? For example, what platforms, and when it will be on the market.
How long do you think it will be until multicast becomes the mainstream delivery method for popular packages over the internet? That would obviously take generally accepted standards, widely-adopted packages, and I expect a lot of expensive Cisco upgrades! Do you forsee it any time soon?
I'm no expert on network protocols. I'm not even a software guy. So some of what follows may seem very naive. Bear with me and see if this makes sense. Here's how I see it working.
Data Rate. The server would send several streams at once on several channels, each one paced for a different data rate. For example, the T1 user would pick a different channel than the 28K modem user. Each channel endlessly repeats the same data set, over & over.
Keeping Track. Each datagram sent would contain an offset value that shows where it fits into the big picture. Thus, the client knows which parts of the whole have been received, and which ones have not. As we shall see, this helps deal with start time synchronisation and dropped packet issues.
Start Time. You don't even try to synchronise start times. If a client connects in the middle, so what. It just stores the second half of the data set, then stays on the line for the next repetition of the first half. The client knows when it has received the whole data set, because each datagram is tagged with an offset that shows where it fits into the big picture.
Missed Packets. This is the hard part. If a client misses a packet because it is dropped en- route, or for whatever reason, there are a few ways to deal with it.
- The client could just wait for the next iteration of the data set, and
listen for the datagrams that fill in the blanks.
- The protocol could use a UDP backchannel which allows clients to request
retransmissions of datagrams by offset. The server could keep track of which
datagrams have been requested, and periodically retransmit those datagrams
out of sequence. If there are too many, and forward progress is threatened,
the server could keep a histogram of which packet have been requested most
often, and resend the most-requested ones only -- let the others wait for the
next iteration.
- My favorite approach: The protocol could get most of the data across,
and just not worry about the occasional gap. Once the client has a mostly-
complete data set, it could use a connected point-to-point protocol to fill
in the gaps. Rsync, for example, is very good at filling small gaps in
otherwise complete data sets. (True, this is point-to-point, and partially
defeats the purpose of using multicast, but since it's only used for
relatively tiny parts of the data set, the connections should be short-lived
and relatively few in number.)
Does any of this make sense?Who will volunteer to re-do this study a little more rationally & post the results here?
(And while we wait for a volunteer, add your suggestions to the following list).
1. State the version of each browser used. Make reasonable effort to use up-to-date ones.
2. For startup time, configure all to initially display blank pages.
3. Include text-only browsers as well (lynx, w3, etc).
4. Use reasonably modern (but not high-end) hardware. At least, enough memory to be support all browser's footprints (i.e. no swap).
5. Separately measure & report "rendering speed" (i.e. from cache or file) and "loading speed" (i.e. with cache flushed).
6. For loading speed: State your internet connection type. Choose a lightly loaded server, at a time of day when your ISP performance is good.
7. Report the actual memory footprint.
8. Report the best unique features (e.g. built in ad-blocker, flexible cookie rejection, whatever.)
9. Report any obvious bad features (e.g. advertising, crashes, etc).
10. Try on a browser compliance test site, and report result. (I know they exist, don't know which is good, though).
Any volunteers to try this and post to Slashdot?
I'd volunteer, but I'm still employed (until Tuesday at least), so I don't have time!
If the mark of a good April Fool's joke is the number of people who think it is serious, this one is a real winner.
(Posting the joke 2 days early is a little tacky, though.)
When I was on an H1 (no B suffix, I think that's a new variation?), I was paid $26K/year. Not great for a an engineer with 5+ years experience. This was 1986-1989, so adjust for inflation if you wish. And it was in one of the highest cost-of-living parts of the US.
I also was constantly subjected to "visa blackmail", where my enployer could demand almost ANYTHING, under direct threat of firing me, knowing that I could not legally work in any other job and would be on the next plane out of the country.
However much some other posters minimize this problem, for me it was VERY real.