And thus, there's a difference between the words "simply" and "easily" I guess. How many routers can perform this statistical analysis in real time? As several people have mentioned in the past, the fact that someone's using encryption *at all* in a world that rarely uses encryption is significant, obviously.
As someone else suggested, they could easily just lock down the SSL port to only allow bursting of a few hundred K and it'd kick in early enough to be a nuisance, I guess.
That said, the tracker doesn't necessarily require that much traffic, and it could easily be engineered to run using stateful, short, connections.
That's curious. How are they defining 'encrypted'? Particular known ports? Content that clearly isn't to a "known port that isn't encrypted"? I can imagine that the former is relatively easy to bypass (nonstandard ports, port redirectors, etc), and the latter being a major issue for gaming of any description...
Does this apply to HTTP over SSL connections? Of course, they simply cannot tell the difference between HTTP over SSL and... well, anything else over "SSL"... And, of course, one could just run, say, bittorrent on port 80....:)
As others have pointed out, Nokia do indeed make OS's, Symbian and their own home-grown variety. Let's also not forget that Qt maintains an embedded edition of their UI toolkit, which may well be very valuable to Nokia.
They're also in the IDE business, since they joined the Eclipse foundation, and have been pumping code into the C/C++ components, so people can use them to work on extensions for their own phones.
No, it's pushed into high priority in order to be able to decode high bitrate video and audio. Like 8000kbps + 5.1 48kHz sort of thing, and make sure that it never, ever, misses a frame due to network interrupts.
Oh, FFS. I really wish people would stop claiming that the audio/video VS network performance issues was a DRM issue. It's just simply not true, no matter which way you try to spin it.
This has already been tried. Tuxracer was originally licensed under the GPL. After it became a bit more complete, the original author formed a company, and tried to make it closed source. End result: fork. He commercialized the code he owned, legitimately, and others took the GPL'ed source, and continued with it.
If you read the DHT specs, it's not really particularly secure, from memory. And it's going to be much harder to prove that a DHT node hasn't been tampered with, without some fairly complex self-repairing code. It's generally discouraged on private trackers as well.
This won't stop ATT from fiddling with your connection to the tracker or to any of the peers.
This is actually pretty easy. We already have a 'trusted' single point here. The Tracker.
If the tracker starts using SSL, and has valid certificates, then there's no risk of man in the middle there (assuming the CA hasn't been compromised, and let's face it, we could easily set up our own for this purpose...). If we extend the tracker protocol to handle the key exchange for us as well, then we have a *secure* key exchange system, that AT&T cannot intercept, filter or screw with, without being relatively obvious.
Then we just have a per-peer key that we generate (even if it's relatively weak, it'd still be far more effort than could be reasonably expended to decypher it by brute force), then even if ATT attaches to the same tracker, they STILL can't get at the content.
The main problem here is that the tracker becomes more cpu-heavy, and trackers already tend to be fairly over utilized
I filed a bug against FreeBSD back in 1998. I didn't get a reply on that ticket until late 2002, if memory serves. Turned out to be a known issue with supporting EIDE, turning that off in the BIOS did the trick, as I discovered, and followed up the ticket myself the next day.
Over 2-3 years later, someone finally closed the ticket.
It's easy to ignore something because you don't realize it's happening to you.
Back in the day, if your privacy was being violated, you'd notice things were moved, or missing. Those telltales are gone in the digital age, where you trust your ISP, your computer, your phone lines, etc, and people don't need to be in the same state as you to peer through your stuff.
People don't get riled up, because it's the least visually intrusive form of intrusion, and it gets painted over with a thin veneer of "finding terrorists", or "protecting the children from child porn" or whatever.
Taking your comment on face value, this only really works if you're communicating with a peer whom you already know, *and* whom you already have exchanged public keys with, in a trusted manner (no, a key on a public key chain isn't trusted, if you don't know why, then you fail at cryptography).
This doesn't work for public discussion lists, or even private ones, unless they're very strictly controlled. It also doesn't help for p2p traffic, as those are between two essentially anonymous parties, and thus, have no way to prevent a man in the middle attack, even if they DO use encryption (unless the tracker mediates, which, for most implementations that I've seen, it doesn't, even if it's using SSL)
The simple fact of the matter is that encryption is the wrong mechanism to solve this problem. Removing power from your government is the right mechanism, ideally.
Removing konqueror doesn't actually remove the web browsing component however. The KHTML component in KDE is part of KDELibs if memory serves. It's really actually very difficult to remove it, more so than removing IE from windows.
Konqueror was just an interface that heavily utilized KHTML, but lots of other programs embedded it as well.
Remember, if you're going to work on OSS stuff, it's a really REALLY good idea to make sure that it's on an area that's not related to your line of employment, and only done in your spare time. If it is work related, discuss it with your employer first, and get it in writing if you're allowed to do it and release it.
Lots of places use it interchangeably, although there is supposed to be a difference in style between the two. I'd definitely use CV when applying to anything remotely academic, and might tend towards using Resume when applying to a business.
You'll be fine, just show them your WA drivers license, cover over the bar code, and tell them to "Get Off My Lawn, Punks!"
I'm pretty sure my immigration lawyers will advise against this course of action pretty strongly.
I'm inclined to agree with the lawyers, since I basically ended up with an effective 100% pay increase when I moved here (Not entirely just because of market differences mind you, the job's definitely more suitable for me). Not about to throw that away and get deported back to Australia by pissing off airport security.
You mean like me, a foreign national, living and working in the US? Nothing stops me getting a drivers license (In fact, I already have one in Washington state.), and I'd be silly to get on a domestic plane without my passport anyway.
Tourists, who hold visa waivers, should rely on their passport (and keep copies in safe places, know the procedures for getting a new one if it gets lost/stolen, etc.) Note that foreign nationals are obliged to have been identified by their own government, not by the American government.
How much you want to trust their government is another matter.
Those popups actually run as SYSTEM, (which is why you can't get hyperlinks in them, incidentally) so you can still apply updates through them. Means that the updating tool needs to be careful, of course.
So ditch all the crappy security that your AP gives out, and use vpn software instead? Then it doesn't really matter how secure the AP is, if it won't go anywhere without an openvpn link with your 1024bit certificate acting as the key.
The main drawback here is that you need something to run openVPN on. Wonder if you can get it running on an openwrt/dd-wrt based wireless router. That and openvpn's not the simplest beast to setup.
You can't really make the assumption that the 'same' equipment is even available. The original set of servers for xbox live would have been purchased several years back. Even with new equipment every 3-6 months, you get your vendors constantly changing hardware.
Sure, you could be on a contract that gives you specific hardware for a year or so, but eventually those change, and you want them to, so that you get those shiny new quad-core systems at almost twice the speed as your old stuff.
Again, now consider maintaining contracts like these for a company that supports 80,000 people worldwide, plus however many billion customers for all of it's product base...
Sure, but are you working for a company with procedures regarding purchasing? You don't just wander down to your local store and say "i'd like a rackmount server plskthx" (or even give dell/whoever a call). You tell ops "we need more capacity for." they say "okay, we've checked all of the current vendors whom we can support, and your options for spending are X, Y or Z." You go "hm, we can afford NxX or MxZ, but Y's support contract is too small. We'll go with M because it's > N."
5-10 days later, ops has the servers. Then ops gets building services to ship them to the labs. Then ops load tests the servers. Then they set it up with management tools, setup backups, and add it to the automation pool. This is about 2-3 weeks later, at best. (remember, ops needs to do this for every other department as well as yours, which for Microsoft, is a *LOT* of departments.)
Then you finally get your hands on it, and can roll your software out, scale test it, etc, fix bugs, make sure that it's solving the problem, go back to the drawing board, because it probably isn't, get software patches in place, etc, and then finally organise the new equipment to go live.
By now, 2-3 months have passed. This is the same in EVERY company I've worked for, including microsoft. The process exists to make sure that people don't get screwed. The problem is, the process is slow, and that's probably unavoidable.
Keep in mind that XBox is a loss leader. They don't have craploads of cash to throw at hardware, because they're living on what is effectively negative margins, in the hopes that licensing will catch up in a few years. Compare this to windows or office, where the profits are enough to fund multiple other new startup projects at once (Including the one I work for, thanks office!:) )
So when someone underestimates the amount of xboxes that are going to get sold over Christmas, you're suddenly finding yourself short to the tune of N% of your required capacity, because you were saving money by operating at 80% instead of the 50% you'd be looking at if you could afford it. Keep in mind that the money from retailers doesn't filter back for a few months, as far as accounts is concerned.
Also, I'm willing to bet that bandwidth isn't the problem so much as simple scaling. This could well be something that just requires some better thinking on the software side, but I don't know much about the inner workings of xbox live's server-side stuff.
Anyway, to put all this into simple words. A bigger company doesn't necessarily mean that scale's an easy problem to deal with.
Let's be clear about this. Copying from disk to disk is a different bottleneck than copying over the network. Network copies are affected by the media playback QoS, AND the relative chattiness of SMB2 (the new version of the CIFS protocol that vista likes to use if it can). Media playback will put an emphasis on prioritising access to media so that it can keep the buffers as full as possible when the QoS service is active (i don't recall what it's called, sorry,) and SMB2 just uses a shitload more packets (and thus, more latency, particularly on busy networks) than SMB1 did.
The DRM components may well be having an effect as well, but it's not the only thing.
Slashdot Mirror
And thus, there's a difference between the words "simply" and "easily" I guess. How many routers can perform this statistical analysis in real time? As several people have mentioned in the past, the fact that someone's using encryption *at all* in a world that rarely uses encryption is significant, obviously.
As someone else suggested, they could easily just lock down the SSL port to only allow bursting of a few hundred K and it'd kick in early enough to be a nuisance, I guess.
That said, the tracker doesn't necessarily require that much traffic, and it could easily be engineered to run using stateful, short, connections.
That's curious. How are they defining 'encrypted'? Particular known ports? Content that clearly isn't to a "known port that isn't encrypted"? I can imagine that the former is relatively easy to bypass (nonstandard ports, port redirectors, etc), and the latter being a major issue for gaming of any description...
:)
Does this apply to HTTP over SSL connections?
Of course, they simply cannot tell the difference between HTTP over SSL and... well, anything else over "SSL"...
And, of course, one could just run, say, bittorrent on port 80....
ash
As others have pointed out, Nokia do indeed make OS's, Symbian and their own home-grown variety. Let's also not forget that Qt maintains an embedded edition of their UI toolkit, which may well be very valuable to Nokia.
They're also in the IDE business, since they joined the Eclipse foundation, and have been pumping code into the C/C++ components, so people can use them to work on extensions for their own phones.
No, it's pushed into high priority in order to be able to decode high bitrate video and audio. Like 8000kbps + 5.1 48kHz sort of thing, and make sure that it never, ever, misses a frame due to network interrupts.
It's a quality of service issue.
Oh, FFS. I really wish people would stop claiming that the audio/video VS network performance issues was a DRM issue. It's just simply not true, no matter which way you try to spin it.
This has already been tried. Tuxracer was originally licensed under the GPL. After it became a bit more complete, the original author formed a company, and tried to make it closed source. End result: fork. He commercialized the code he owned, legitimately, and others took the GPL'ed source, and continued with it.
If you read the DHT specs, it's not really particularly secure, from memory. And it's going to be much harder to prove that a DHT node hasn't been tampered with, without some fairly complex self-repairing code. It's generally discouraged on private trackers as well.
This won't stop ATT from fiddling with your connection to the tracker or to any of the peers.
This is actually pretty easy. We already have a 'trusted' single point here. The Tracker.
If the tracker starts using SSL, and has valid certificates, then there's no risk of man in the middle there (assuming the CA hasn't been compromised, and let's face it, we could easily set up our own for this purpose...). If we extend the tracker protocol to handle the key exchange for us as well, then we have a *secure* key exchange system, that AT&T cannot intercept, filter or screw with, without being relatively obvious.
Then we just have a per-peer key that we generate (even if it's relatively weak, it'd still be far more effort than could be reasonably expended to decypher it by brute force), then even if ATT attaches to the same tracker, they STILL can't get at the content.
The main problem here is that the tracker becomes more cpu-heavy, and trackers already tend to be fairly over utilized
ash
That would mean you probably hate Tarantella. Hate to tell you, but they still exist.
Shake your fist in impotent rage!
I filed a bug against FreeBSD back in 1998. I didn't get a reply on that ticket until late 2002, if memory serves. Turned out to be a known issue with supporting EIDE, turning that off in the BIOS did the trick, as I discovered, and followed up the ticket myself the next day.
Over 2-3 years later, someone finally closed the ticket.
These things happen.
It's easy to ignore something because you don't realize it's happening to you.
Back in the day, if your privacy was being violated, you'd notice things were moved, or missing. Those telltales are gone in the digital age, where you trust your ISP, your computer, your phone lines, etc, and people don't need to be in the same state as you to peer through your stuff.
People don't get riled up, because it's the least visually intrusive form of intrusion, and it gets painted over with a thin veneer of "finding terrorists", or "protecting the children from child porn" or whatever.
Taking your comment on face value, this only really works if you're communicating with a peer whom you already know, *and* whom you already have exchanged public keys with, in a trusted manner (no, a key on a public key chain isn't trusted, if you don't know why, then you fail at cryptography).
This doesn't work for public discussion lists, or even private ones, unless they're very strictly controlled.
It also doesn't help for p2p traffic, as those are between two essentially anonymous parties, and thus, have no way to prevent a man in the middle attack, even if they DO use encryption (unless the tracker mediates, which, for most implementations that I've seen, it doesn't, even if it's using SSL)
The simple fact of the matter is that encryption is the wrong mechanism to solve this problem. Removing power from your government is the right mechanism, ideally.
Removing konqueror doesn't actually remove the web browsing component however. The KHTML component in KDE is part of KDELibs if memory serves. It's really actually very difficult to remove it, more so than removing IE from windows.
Konqueror was just an interface that heavily utilized KHTML, but lots of other programs embedded it as well.
Not so sure about America (since it's not as based on common law as Australia is) but it's certainly happened in Australia.
Low brow version
Medium brow
High brow legal paperwork
Remember, if you're going to work on OSS stuff, it's a really REALLY good idea to make sure that it's on an area that's not related to your line of employment, and only done in your spare time. If it is work related, discuss it with your employer first, and get it in writing if you're allowed to do it and release it.
Actually, Curriculum Vitae is still fairly widely used.
http://en.wikipedia.org/wiki/Curriculum_vitae#Terminology
Lots of places use it interchangeably, although there is supposed to be a difference in style between the two. I'd definitely use CV when applying to anything remotely academic, and might tend towards using Resume when applying to a business.
ash
Yes. It has a positive bias in the title (pro open source) instead of a negative one. We want slashdot to be fair and impartial right....?
ash
Didn't you see the Italian Job or Die Hard 4?
You'll be fine, just show them your WA drivers license, cover over the bar code, and tell them to "Get Off My Lawn, Punks!"
I'm pretty sure my immigration lawyers will advise against this course of action pretty strongly.
I'm inclined to agree with the lawyers, since I basically ended up with an effective 100% pay increase when I moved here (Not entirely just because of market differences mind you, the job's definitely more suitable for me). Not about to throw that away and get deported back to Australia by pissing off airport security.
Those pesky foreigners that keep visiting the US?
You mean like me, a foreign national, living and working in the US? Nothing stops me getting a drivers license (In fact, I already have one in Washington state.), and I'd be silly to get on a domestic plane without my passport anyway.
Tourists, who hold visa waivers, should rely on their passport (and keep copies in safe places, know the procedures for getting a new one if it gets lost/stolen, etc.) Note that foreign nationals are obliged to have been identified by their own government, not by the American government.
How much you want to trust their government is another matter.
ash
Those popups actually run as SYSTEM, (which is why you can't get hyperlinks in them, incidentally) so you can still apply updates through them. Means that the updating tool needs to be careful, of course.
ash
So ditch all the crappy security that your AP gives out, and use vpn software instead? Then it doesn't really matter how secure the AP is, if it won't go anywhere without an openvpn link with your 1024bit certificate acting as the key.
The main drawback here is that you need something to run openVPN on. Wonder if you can get it running on an openwrt/dd-wrt based wireless router. That and openvpn's not the simplest beast to setup.
ash
I'm pretty sure there's going to be import duties on a 5kt nuke or 10 pounds of C4 or something.... :)
You can't really make the assumption that the 'same' equipment is even available. The original set of servers for xbox live would have been purchased several years back. Even with new equipment every 3-6 months, you get your vendors constantly changing hardware.
Sure, you could be on a contract that gives you specific hardware for a year or so, but eventually those change, and you want them to, so that you get those shiny new quad-core systems at almost twice the speed as your old stuff.
Again, now consider maintaining contracts like these for a company that supports 80,000 people worldwide, plus however many billion customers for all of it's product base...
ash
Sure, but are you working for a company with procedures regarding purchasing? You don't just wander down to your local store and say "i'd like a rackmount server plskthx" (or even give dell/whoever a call). You tell ops "we need more capacity for ." they say "okay, we've checked all of the current vendors whom we can support, and your options for spending are X, Y or Z." You go "hm, we can afford NxX or MxZ, but Y's support contract is too small. We'll go with M because it's > N."
:) )
5-10 days later, ops has the servers. Then ops gets building services to ship them to the labs. Then ops load tests the servers. Then they set it up with management tools, setup backups, and add it to the automation pool. This is about 2-3 weeks later, at best. (remember, ops needs to do this for every other department as well as yours, which for Microsoft, is a *LOT* of departments.)
Then you finally get your hands on it, and can roll your software out, scale test it, etc, fix bugs, make sure that it's solving the problem, go back to the drawing board, because it probably isn't, get software patches in place, etc, and then finally organise the new equipment to go live.
By now, 2-3 months have passed. This is the same in EVERY company I've worked for, including microsoft. The process exists to make sure that people don't get screwed. The problem is, the process is slow, and that's probably unavoidable.
Keep in mind that XBox is a loss leader. They don't have craploads of cash to throw at hardware, because they're living on what is effectively negative margins, in the hopes that licensing will catch up in a few years. Compare this to windows or office, where the profits are enough to fund multiple other new startup projects at once (Including the one I work for, thanks office!
So when someone underestimates the amount of xboxes that are going to get sold over Christmas, you're suddenly finding yourself short to the tune of N% of your required capacity, because you were saving money by operating at 80% instead of the 50% you'd be looking at if you could afford it. Keep in mind that the money from retailers doesn't filter back for a few months, as far as accounts is concerned.
Also, I'm willing to bet that bandwidth isn't the problem so much as simple scaling. This could well be something that just requires some better thinking on the software side, but I don't know much about the inner workings of xbox live's server-side stuff.
Anyway, to put all this into simple words. A bigger company doesn't necessarily mean that scale's an easy problem to deal with.
ash
Let's be clear about this. Copying from disk to disk is a different bottleneck than copying over the network. Network copies are affected by the media playback QoS, AND the relative chattiness of SMB2 (the new version of the CIFS protocol that vista likes to use if it can). Media playback will put an emphasis on prioritising access to media so that it can keep the buffers as full as possible when the QoS service is active (i don't recall what it's called, sorry,) and SMB2 just uses a shitload more packets (and thus, more latency, particularly on busy networks) than SMB1 did.
The DRM components may well be having an effect as well, but it's not the only thing.
ash