Many dual-connected nodes automatically try to route traffic over Internet2 if
possible, so if you're accessing a node that's connected to Internet2, you are
probably using the Internet2 connection to get there no matter what kind of
traffic it is.
So, in order to spy on all the traffic between Internet2 nodes,
such as a file sharing network connecting a few universities together (which
would automatically use the Internet2 connection), they would need access to
Internet2.
Isn't it more expensive to measure P2P traffic accurately?
It seems to me that scanning the actual content of every packet would eat up a lot of processing time on a busy network/hub/etc. Unless,
of course, the media companies ask for help from the all powerful NSA.
How could you accurately (and more importantly quickly) determine whether some traffic is some P2P program as the article suggests when you have a really BIG haystack and a tiny needle?
How about the linux-kernel mailing list? The kernel programmers have to always
keep how the computer handles a piece of code in mind. For example, two pieces
of similar looking code could have vast performance differences due to cache
and branching behaviors, which is discussed often on the mailing list.
Many programmers don't really pay attention to how their code is handled and
create code that "looks" good but performs badly.
I thought the daily doubles were never in the lowest point slot (never in
the $200 slot for Single Jeopardy, and never in the $400 slot for Double
Jeopardy). So you'd have ((3000*6)-400)*2 = 35200 for the first round
(optimally having the single daily double at the end in one 400 slot).
Then in Double Jeopardy, you'd have (35200 + ((6000*6)-800-800)) * 2 * 2 = 278400
(optimally having the two daily doubles at the end in two 800 slots)
then double it again for final to get 556800.
Possibly worse are languages that let you define your own syntax.
Imagine something similar to #define in C, except you could specify what symbols
you wanted to use to separate each argument.
The TADS3 language uses this extensively to allow you to define shortcuts
when defining an object. You can look at some examples
here.
Encryption in a database just doesn't seem to make much sense to me, unless you want to
force an end-user to type in a password upon every single access to a column in the
database. Otherwise there's a chance that someone could just snarf the
encryption/decryption keys out of the server's memory.
Yes, reattaching to a running program is the primary function of dtach. You
are not able to do that with the disown command. dtach also lets you attach
multiple times to the same program.
Right, this segment-level protection is what the various no-execute patches do
for x86. It isn't as easy to use as it looks, though, and there can only be
one code segment at a time.
Modern OSes set up the code, data, and stack segments to point to the same
region of memory, and programs expect to be able to access the entire 32-bit
address space without needing special kinds of pointers (aka the joys of near,
far, and huge pointers in old DOS programs.)
Thus, the only practical way to make the code segment non-executable is to try
and move all code to the bottom of memory, and basically prevent the rest of
the 32-bit address range from ever being executable. Many programs don't work
under this restriction (such as programs that dynamically load or create code
at runtime.)
What people are talking about here is the ability to mark any page in memory
as being non-executable, which allows the OS to avoid using a huge
sledgehammer to fix the problem.
The x86 only has two bits per page, Readable and Writable. You can't mark a
page of memory as readable without marking it as being executable, they are the
same thing on the x86.
The no-exec stack patches use a huge sldgehammer to try and work around this
limitation. All code is moved to the very bottom of the 32-bit address space,
and the code segment is limited in size (normally all segments can see the
entire address space.) However, it is not always possible to do this flawlessly, and many programs don't tolerate it well.
The OS isn't the problem, most OSes already keep code and data is separate segments.
The problem is the x86 chip, which has no separate execute permission bit for
memory, and assumes that anything that's readable is also executable. This
makes it hard to protect random pages on the x86. The no-exec patches for x86
use various tricks to try and work around this limitation, but it's still not
as good as having a separate execute bit per page of memory.
I think that most people that care about battery life for their portable devices (such as a laptop) keep those devices unplugged most of the time.
Why would I be worrying about battery life if I am always using AC power?
If I understand the article correctly, it says that this new battery can only be recharged 300 times, and each recharge only lasts about 8 hours. This means that each battery will only last about 87 days, right?
Presumably, the price of the new battery will be higher than existing batteries, and it sounds like it could be a big annoyance factor to be worse than existing batteries. Would anyone spend the extra money for something that isn't that much better than what we have now? Supply and demand, and all that.
I really dislike the new interface for Usenet. Compared with the current one it's much harder to use and much more bloated. Google, until now, usually had minimal pages with no unnecessary fluff.
I was also thinking about a similar system to the one described in the article, except using ping packets instead of using connections to random TCP ports.
The ping command in Unix allows you to specify up to 16 bytes to be sent with the ping packet, i.e. a password, which could be detected by the firewall and if it's correct, then some action could be taken. As a bonus, the standard Windows version of ping doesn't appear to support this feature.
I think such a scheme could be made using a stateful firewall. For example, using iptables and Linux 2.6, it could be done using the ipt_string and ipt_recent modules.
Slashdot Mirror
So, in order to spy on all the traffic between Internet2 nodes, such as a file sharing network connecting a few universities together (which would automatically use the Internet2 connection), they would need access to Internet2.
How could you accurately (and more importantly quickly) determine whether some traffic is some P2P program as the article suggests when you have a really BIG haystack and a tiny needle?
Many programmers don't really pay attention to how their code is handled and create code that "looks" good but performs badly.
Then in Double Jeopardy, you'd have (35200 + ((6000*6)-800-800)) * 2 * 2 = 278400 (optimally having the two daily doubles at the end in two 800 slots) then double it again for final to get 556800.
Or dtach, with most sane full-screen programs. :)
The TADS3 language uses this extensively to allow you to define shortcuts when defining an object. You can look at some examples here.
Rare, medium, or well-done?
Encryption in a database just doesn't seem to make much sense to me, unless you want to force an end-user to type in a password upon every single access to a column in the database. Otherwise there's a chance that someone could just snarf the encryption/decryption keys out of the server's memory.
...make sure you always use protection when seeking the advice of a medical professional.
Why would someone want to use this instead of PostgreSQL?
Try the "Practical Guide" series by Mark Sobell; the homepage is here.
Yes, reattaching to a running program is the primary function of dtach. You are not able to do that with the disown command. dtach also lets you attach multiple times to the same program.
Modern OSes set up the code, data, and stack segments to point to the same region of memory, and programs expect to be able to access the entire 32-bit address space without needing special kinds of pointers (aka the joys of near, far, and huge pointers in old DOS programs.)
Thus, the only practical way to make the code segment non-executable is to try and move all code to the bottom of memory, and basically prevent the rest of the 32-bit address range from ever being executable. Many programs don't work under this restriction (such as programs that dynamically load or create code at runtime.)
What people are talking about here is the ability to mark any page in memory as being non-executable, which allows the OS to avoid using a huge sledgehammer to fix the problem.
Well, all executable memory has to also be readable on the x86. :)
The no-exec stack patches use a huge sldgehammer to try and work around this limitation. All code is moved to the very bottom of the 32-bit address space, and the code segment is limited in size (normally all segments can see the entire address space.) However, it is not always possible to do this flawlessly, and many programs don't tolerate it well.
The OS isn't the problem, most OSes already keep code and data is separate segments. The problem is the x86 chip, which has no separate execute permission bit for memory, and assumes that anything that's readable is also executable. This makes it hard to protect random pages on the x86. The no-exec patches for x86 use various tricks to try and work around this limitation, but it's still not as good as having a separate execute bit per page of memory.
According to the T-Mobile girl, you can always take your number to a better place!
Well, they have "their own alphabet, their own language, [and] their own hand signals", so they already fit in perfectly with most Internet chatters.
I wonder how many of them will claim that it wasn't really them becasue of a worm or virus or someone else using their password.
I think that most people that care about battery life for their portable devices (such as a laptop) keep those devices unplugged most of the time. Why would I be worrying about battery life if I am always using AC power?
Presumably, the price of the new battery will be higher than existing batteries, and it sounds like it could be a big annoyance factor to be worse than existing batteries. Would anyone spend the extra money for something that isn't that much better than what we have now? Supply and demand, and all that.
Or am I missing something?
As an example, try viewing a newsgroup with the old and new interfaces: Compare the old interface with the new interface.
I hope they don't remove the old interface for Usenet.
Except the new interface sucks compared to the old one. I hope they don't get rid of the current Usenet archive interface.
I was also thinking about a similar system to the one described in the
article, except using ping packets instead of using connections to
random TCP ports.
The ping command in Unix allows you to specify up to 16 bytes to be sent
with the ping packet, i.e. a password, which could be detected by the
firewall and if it's correct, then some action could be taken. As a
bonus, the standard Windows version of ping doesn't appear to support
this feature.
I think such a scheme could be made using a stateful firewall. For example,
using iptables and Linux 2.6, it could be done using the ipt_string and
ipt_recent modules.
Is this what you mean by archive log mode? If so, then PostgreSQL has it. :)