States are NOT restricted from holding copyright in general (only the federal government is). There are some exceptions to this, but they probably don't apply here.
On the face of it this seems like a perfectly legitimate complaint on the part of the state. The state is expected to assume the cost of producing the laws themselves (that's why we pay legislative salaries), and making those things freely available in order to enforce them, but the indexing, research, and reference work involved in creating an annotated version costs money and isn't guaranteed to be done by statute, meaning that it could be covered by copyright and the state is reasonably justified in attempting to recover those costs. There are of course many complexities here (although almost all of them will be found in Georgia law itself, and have nothing to do with the federal constitution), but the suit is far less unreasonable than the poorly researched editorial "reporting" it.
Since no one here actually read the opinion, and/. has once again engaged in sensationalism (what else is new), I feel it necessary to point out a few things:
* NONE of this data included GPS data from the phone * NONE of this data included ANY data from the phone AT ALL * NONE of this data included ANY kind of location data when the phone was not in use
The data in question is toll record data that indicates a phone number and the cell tower it is using to make a call. Obviously this information isn't very precise to start with, so wasn't central to the actual trial in the first place. If the government had wanted to get GPS or "prospective location" information ('pings' from unused phones as they traverse space) that has been fairly well litigated already as requiring a warrant (not saying people don't break rules, but the case law there is much clearer). This was a very fine point that is not earthshattering or groundbreaking in any way (basically a translation of existing Call Detail Record landline data case law to the mobile space).
The mistake he made was not understanding the tools he was using. Apparently neither do you.
(1) The key could have been scraped at any time once it was pushed, because you can't actually "delete[d] all traces from GitHub" (some ways are more thorough than others, but nothing is foolproof with Google wandering the earth). He needed to revoke his keys immediately.
(2) There is no such thing as an "S3 key". There are only AWS API keys, which potentially have access to every service that you have enabled (plus the default ones). You need to use IAM profiles to restrict what services they can access, and what rights they have.
Signing up for a service and then using it without reading the documentation is foolish.
This type of problem has been reported many times before, with much more knowledgable writeups.
The original poster is so naive that they didn't even bother to read enough Amazon documentation to realize there is no such thing as an "S3 key" - API access by AWS keys is limited only by the IAM profile of the key (and my guess is that the OPs keys were unrestricted). They also apparently didn't realize how version control systems work, otherwise they would have known that deleting the key from a revision doesn't actually remove it from the history of the repository.
This article isn't doing anyone any favors - if you want to actually help the community then maybe source an original article reminding people that they should read the docs and understand the services they're using, with pointers to the relevant warnings for commonly used services (both github and amazon have prominent notices with service-relevant notes about how to protect your sensitive data).
Years ago, before Amazon as you put it "created cloud computing", the running joke was that they made a loss on every sale but made up for it in volume. So yes, basically, for years on end when they were just a retailer they were propped up making a substantial loss for years on end.
Perhaps you should rephrase this as "for years on end when they were a startup, they were losing money while growing revenues and gaining market penetration".
Every year from 2003 to 2011 amazon posted a net profit, with a very small loss in 2012 (which wasn't really a good year for anyone).
They didn't launch EC2 as a product until 2006, so clearly they were making money before that, and it's not a significant percentage of their revenue even now. AMZN recorded $2.5Bn in "other" revenue in 2012 (this includes AWS, but also includes credit card agreements and advertising services, so the AWS number is somewhat less than the total), and just over $61Bn in total revenue. Even assigning all "other" revenue to AWS means that it nets out at barely 4% of total revenue.
In fact Amazon it often takes losses quarters on end. I don't have the time to search for the actual figures, but I am pretty sure they have been operating at a loss since 3rd quarter 2012.
This information is freely and easily accessible on the internet. You're aware of the internet, right?
Amazon posted positive net income in 4Q 2012 ($98M), and 1Q 2013 ($82M).
They either have a contractual right to perform reasonable security audits from an external source, or they don't, and if you wish to pursue some remedy this is the only thing that matters.
That being said, if someone told you they were performing a security audit, it wouldn't be much of one. The whole *point* is that it shouldn't matter to you whether the test was authorized or not - a real attacker doesn't care about authorization. Complaining about a pentest to slashdot is not really useful - this is a legal matter. As a technical matter if you care about a pentest which likely isn't causing any kind of denial of service, you've got problems with your outlook on security.
We never had a 300 baud modem, thank god....my father worked for the local computer retailer, so we got the top of the line (Atari!) 1200 baud modem when it became available. Before that we'd go to the library to get on Cleveland Freenet (1988)....we still used it for a while after that with our own modem, but then we went with Delphi ($40 for 40 meg a month! Who would use 40MB a month!).
Ah, the good old days. It reminds me of the craziness with zmodem, ymodem-g, etc. Of course, those were the days when you would *really* consider whether you wanted to download something larger than 100KB (usually from umich...)
In 2007 Google reported that for a sample of 100k drives, only 60% of their drives with failures had ever encountered any SMART errors. Also, NetApp has reported a significant amount of drives with temporary failures, such that they can be placed back into a pool after being taken offline for a period of time and wiped. Google also had a lot of other interesting things to say (such as heat has no noticeable effect on hard drive life under 45C, that load is unrelated to failure rates, and that if a drive doesn't fail after 3 months, it's very unlikely to fail until the 2-3 year timeframe.
A few other notes that you can find from storage vendor tech notes if you own their arrays:
* Enterprise-level SAS drives aren't any more reliable than consumer SATA drives
- But they do have considerably different firmwares that assume they will be placed in an array, and thus have a completely different self-healing scheme than consumer-level drives (generally resulting in higher performance in failure scenarios)
* RAID 5 is a really bad idea - correlated failures are much more likely than the math would indicate, especially with the rebuild times involved with today's huge drives
* You have a lot more filesystem options that might not even make sense to use with a RAID system, like ZFS, as well as other mechanisms for distributing your data at a layer higher than the filesystem
Ultimately the reality is that regardless of the testing you put them under, hard drives will fail, and you need to design your production system around this fact. You *should* burn them in with constant read/write cycles for a couple days in order to identify those drives which are essentially DOA, but you shouldn't assume any drive that passes that process won't die tomorrow.
First of all, I don't know what you're doing building the SPEC tests with GCC on Sparc, since that's hardly a test of optimal performance. Building with the SunPro compiler is not only the right thing to do (shouldn't be hard to believe that Sun's compiler optimizes better for their own hardware), but it also happens to compile just fine on the 1500.
Also, I don't have a lot of respect for someone who claims that WD hard drives are of better quality than Seagate drives. As someone who has killed every WD drive I've ever seen in a real workstation environment, I'll take a Seagate any day, even if it is IDE.
Two important things to remember about the turbo diesel's from VW:
1) Diesel isn't all that easy to find in some parts of the US
2) The emissions from a gallon of diesel are quite a lot worse than a gallon of unleaded, and the process used to refine it is also a lot more polluting.
I have a Treo 300, and its' GPS capability can be used by Palm applications, so the statement that US phones don't offer positioning information to the user is false. Also, for the paranoid, you can disable palm application access to the GPS unit so that AOL can't track you while you're on Instant Messenger...;-)
You need a NEMA 4X enclosure, like those used in industrial settings. They're fully sealed and can withstand such incidents as being drenched in hydraulic fluid, and being dunked in water.
The main problem you're going to have is possibly overheating, as there is no ventilation since you want to keep the salt out of the system. Cooling is done by raidating heat through the surface of the box, which may not be sufficient for a high power PC. The systems that I've placed in factories and test facilities have typically been much lower power than your average PC, and the individual components were engineered to withstand the harsh environment as well.
I've used both Rittal and Hoffman in the past and been quite pleased with their enclosures and their support. Other companies may be as good, of course, but I haven't worked with them.
The one thing you will probably want to avoid, depending on your environment, is a NEMA 4X keyboard. PC keyboards are cheap, and you will not enjoy using a membrane keyboard for an extended period of time. A salt water environment on a sail boat is nowhere near as harsh as a hydraulic test lab, so your PC keyboard will probably last at least a few months. i think $20-$50 every three months is a cheap price to pay for the comfort of a real keyboard.
>No, MacOS X does not have this feature natively
>implemented.
I don't see anywhere where it says that natively implemented means that it has to be accessible through some sort of nifty clicking in the window. It *IS* natively implemented in the OS, and is a standard property setting in all Quartz-based applications. It's of course left to the application developer whether they allow you to change that setting via the preferences of their application. However, even if they don't, you can use the plist editor (or the command line) to add the property to any native application.
Well, there you go, now every moron on the planet has puck's NOC list. If this guy *knew* anything from the start, he'd already *have* the NOC list. Basically, if you haven't got the NOC list, you obviously didn't know what you were doing anyhow. Slashdot is *not* the forum for this kind of request. Go to inet-access, or NANOG, and ask for NOC contact information. You're inability to contact their NOC does not mean that everybody on the planet needs to learn about your problem.
Re:Another silly machine from Sun's marketing dept
on
New Machines From Sun
·
· Score: 1
If you were to, say, for example, pull your head out of the sand, you would realize a couple of things:
1) It has 2 10/100 ethernet ports
2) It uses PC133 ram
3) Why the heck do you need video on a server?
Sure, IDE means that it isn't for everybody, but farming these things as web servers will be great.
As I said in a previous comment, the quotes are taken out of context. What he actually meant was that they relied on the ISP for physical security of the box, which makes sense. They don't leave an FBI agent there to guard it.
This is reasonable because the ISP shouldn't want anyone else accessing their traffic, and if you're worried about the ISP changing the filter settings, they can already access all of your information anyhow. He's just saying that the box is left at the NOC, and is subject to the same kind of security as the NOC itself.
A small company named Enkido was the first to ever offer OC-768 transit, in Manhatten, back in May.
What's even better, if you're talking last mile, you should move to Manhatten, where Enkido has that OC-768 service within 200 feet of *anywhere* on the island (they have 3500 miles of fibre on the island). As with Qwest, they're carrying 40Gbps on a single lamba (wavelength), so they currently peak out at 6.4Tbps, although hopes of ever *routing* that are pretty low at this point.
This is most likely correct. To get a product to market in a timely manner, Microsoft will merely 'carbonate' their app, which is to say that they will remove all calls to deprecated MacOS API's, and use the slimmed down API set known as carbon, which plays nice with OS X.
Microsoft has already produced a Carbon version of IE5 for MacOS X DP4, so that product should actually be quite useable when OS X ships. As for Office, especially from Microsoft, that's probably a fairly, well, huge, codebase.
In any case, what this all means is that *BSD folks are still out in the cold as far as an Office suite from Microsoft. Not that most of them would mind, probably.
However, there is about a snowballs' chance in hell that Microsoft is porting Office to the Cocoa API's, the native MacOS X API. If that were the case, *BSD users would be closer to having a suite, but that would still require a port of parts of CoreFoundation that aren't OpenSource, although a lot of it is. GNUStep might be able to fill in the blanks where CF isn't available.
Why would Microsoft do this? Well, it's *probable* that Apple has quite a bit of Cocoa ported to win32, since that may have been their original plan. Obviously, they've shied away from the win32/x86 crowd at the moment, at least for a full product, probably because of lack of engineering hours to spend on the project, but who knows what else that $150 million deal with Microsoft included.
Of course, the latter part is likely all pipe dream, but it's a nice dream, isn't it?:-) With Cocoa available on Win32, MacOS X, and GNUStep providing API compatibility on other *nix systems, we would have a truly excellent cross-platform development toolkit. Of course, another strike against this idea is that Microsoft is not likely to want to port Office to Obj-C, and while that isn't the only language that Apple supports, it's a major player.
This is, of course, not unlike British Airways banning Salman Rushdie from flying on their aircraft for fear of an attack on the plane.
Do I think that it's right, in a civil liberties kind of way? I'm not sure. Obviously, it sucks for Mr. Rushdie, and it's not too pleasing for the user who got removed from their ISP, but on the other hand, we have a greater good to consider. (And don't go ranting about me spewing any kind of 'greater good' crap...it's not quite like that).
Realistically, if the ISP is targeted because of the content brought forth by one user (not in violation of any AUP), and, as such, the ISP loses its' connection to the net, or is very congested at the least, the ISP isn't doing anybody any favors by keeping that user. Other users would probably prefer surfing over the possibility of their ISP taking some idealogical stand, and the user in question isn't going to be getting their message out anyhow, given that no one can reach the ISP.
However, we're going to have to draw the line in the sand somewhere. If script kiddies can get opposing or controversial views from being disseminated by denying service to a greater mass of users, that doesn't set a good precedent. It's kind of like the internet equivalent of an economic embargo. We don't like what you stand for, so you're not going to get any packets. Besides, if script kiddies can do it, what's going to stop operatives from world governments doing the same?
Obviously, the real solution here is better cooperation among ISPs so that DoS attacks can be tracked down in a timely manner, and the perpetrators can be dealt with. And now we're back to what seems to be a common issue these days. A great deal of the Evils(tm) of the Internet today could be resolved if service providers would treat each other as equals, as they once did in the NFSNet days (and even in several years after). Granted, they are competitors, and not all ISPs are created equal, but this network doesn't work without cooperation. If we didn't have cooperation, we'd just have a bunch of big WANs that weren't attached to each other.
Let the marketing and sales guys go at each others' throats, but let the tech guys have each others' phone numbers.
Go to Compaq's web site, download the plans, and build one yourself..:-)
Honestly, though, there aren't any seriously expensive or hard to find components in that device. You might have been able to convince me a few months ago that ARM chips were in short supply, but with the number of companies shipping products based on it going up, I think we would have heard of any production problems.
Realistically, it may just be that Compaq doesn't see a market for it. However, it may not cost them too much more to actually produce and ship it. Obviously, if they don't plan on shipping it, they've already acknowledged that they're going to take a loss on the research and development, so recovering that cost should be a non-issue at this point. The real cost actually comes from advertising/marketing (if they want to seriously push the product) and with production time. These wouldn't be that hard to pump off the line, but that means that they have a production line that isn't producing something else, which perhaps was a more profitable product. There's plenty more random reasons as well (like the PDA market is really heating up and getting seriously competitve at this point, and you can't make a lot of money just on the few gear-heads who buy your product because its' guts are cool). A lot of things have to happen before you can release a product to market.
But, putting all that aside, I've heard that they will be shipping a product around Christmas.
But Konrad filed his patent on August 14, 1997, which pretty much means he's screwed. Even if he *did* invent client/server computing, which I doubt, if more than a year passed between the time which he published a paper and when he filed for the patent, he can't get the patent anymore. This means that even if he did invent it, he could have published a paper about it no earlier than August 14, 1996, and, as we're all aware, there are plenty of previous examples of prior art, dating even back to the 60's, with mainframes and timesharing systems.
If he's really pursing this avenue of 'I own POST and GET', then he's not doing himself any favors. I don't believe that anyone would have percieved his patent to be that broad, and, as such, would never have brought up all this prior art, but since he's going after someone, his entire patent is likely to be thrown out, which certainly isn't what he intended.
This is a standard Cobalt Qube, except I believe that it's black (anybody know for sure? the pic on gateway's site shows it as black, but it might just be black & white). Gateway and Cobalt announced a deal all the way back in October of last year, and this machine has been available for quite some time. Not sure if it made/. the first time around.
Slashdot Mirror
States are NOT restricted from holding copyright in general (only the federal government is). There are some exceptions to this, but they probably don't apply here.
On the face of it this seems like a perfectly legitimate complaint on the part of the state. The state is expected to assume the cost of producing the laws themselves (that's why we pay legislative salaries), and making those things freely available in order to enforce them, but the indexing, research, and reference work involved in creating an annotated version costs money and isn't guaranteed to be done by statute, meaning that it could be covered by copyright and the state is reasonably justified in attempting to recover those costs. There are of course many complexities here (although almost all of them will be found in Georgia law itself, and have nothing to do with the federal constitution), but the suit is far less unreasonable than the poorly researched editorial "reporting" it.
Since no one here actually read the opinion, and /. has once again engaged in sensationalism (what else is new), I feel it necessary to point out a few things:
* NONE of this data included GPS data from the phone
* NONE of this data included ANY data from the phone AT ALL
* NONE of this data included ANY kind of location data when the phone was not in use
The data in question is toll record data that indicates a phone number and the cell tower it is using to make a call. Obviously this information isn't very precise to start with, so wasn't central to the actual trial in the first place. If the government had wanted to get GPS or "prospective location" information ('pings' from unused phones as they traverse space) that has been fairly well litigated already as requiring a warrant (not saying people don't break rules, but the case law there is much clearer). This was a very fine point that is not earthshattering or groundbreaking in any way (basically a translation of existing Call Detail Record landline data case law to the mobile space).
The mistake he made was not understanding the tools he was using. Apparently neither do you.
(1) The key could have been scraped at any time once it was pushed, because you can't actually "delete[d] all traces from GitHub" (some ways are more thorough than others, but nothing is foolproof with Google wandering the earth). He needed to revoke his keys immediately.
(2) There is no such thing as an "S3 key". There are only AWS API keys, which potentially have access to every service that you have enabled (plus the default ones). You need to use IAM profiles to restrict what services they can access, and what rights they have.
Signing up for a service and then using it without reading the documentation is foolish.
This type of problem has been reported many times before, with much more knowledgable writeups.
The original poster is so naive that they didn't even bother to read enough Amazon documentation to realize there is no such thing as an "S3 key" - API access by AWS keys is limited only by the IAM profile of the key (and my guess is that the OPs keys were unrestricted). They also apparently didn't realize how version control systems work, otherwise they would have known that deleting the key from a revision doesn't actually remove it from the history of the repository.
This article isn't doing anyone any favors - if you want to actually help the community then maybe source an original article reminding people that they should read the docs and understand the services they're using, with pointers to the relevant warnings for commonly used services (both github and amazon have prominent notices with service-relevant notes about how to protect your sensitive data).
Years ago, before Amazon as you put it "created cloud computing", the running joke was that they made a loss on every sale but made up for it in volume. So yes, basically, for years on end when they were just a retailer they were propped up making a substantial loss for years on end.
Perhaps you should rephrase this as "for years on end when they were a startup, they were losing money while growing revenues and gaining market penetration".
Every year from 2003 to 2011 amazon posted a net profit, with a very small loss in 2012 (which wasn't really a good year for anyone).
They didn't launch EC2 as a product until 2006, so clearly they were making money before that, and it's not a significant percentage of their revenue even now. AMZN recorded $2.5Bn in "other" revenue in 2012 (this includes AWS, but also includes credit card agreements and advertising services, so the AWS number is somewhat less than the total), and just over $61Bn in total revenue. Even assigning all "other" revenue to AWS means that it nets out at barely 4% of total revenue.
In fact Amazon it often takes losses quarters on end. I don't have the time to search for the actual figures, but I am pretty sure they have been operating at a loss since 3rd quarter 2012.
This information is freely and easily accessible on the internet. You're aware of the internet, right?
Amazon posted positive net income in 4Q 2012 ($98M), and 1Q 2013 ($82M).
They either have a contractual right to perform reasonable security audits from an external source, or they don't, and if you wish to pursue some remedy this is the only thing that matters.
That being said, if someone told you they were performing a security audit, it wouldn't be much of one. The whole *point* is that it shouldn't matter to you whether the test was authorized or not - a real attacker doesn't care about authorization. Complaining about a pentest to slashdot is not really useful - this is a legal matter. As a technical matter if you care about a pentest which likely isn't causing any kind of denial of service, you've got problems with your outlook on security.
We never had a 300 baud modem, thank god....my father worked for the local computer retailer, so we got the top of the line (Atari!) 1200 baud modem when it became available. Before that we'd go to the library to get on Cleveland Freenet (1988)....we still used it for a while after that with our own modem, but then we went with Delphi ($40 for 40 meg a month! Who would use 40MB a month!).
Ah, the good old days. It reminds me of the craziness with zmodem, ymodem-g, etc. Of course, those were the days when you would *really* consider whether you wanted to download something larger than 100KB (usually from umich...)
Not completely related to how to test, but...
In 2007 Google reported that for a sample of 100k drives, only 60% of their drives with failures had ever encountered any SMART errors. Also, NetApp has reported a significant amount of drives with temporary failures, such that they can be placed back into a pool after being taken offline for a period of time and wiped. Google also had a lot of other interesting things to say (such as heat has no noticeable effect on hard drive life under 45C, that load is unrelated to failure rates, and that if a drive doesn't fail after 3 months, it's very unlikely to fail until the 2-3 year timeframe.
You can find the google paper here: http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/disk_failures.pdf
A few other notes that you can find from storage vendor tech notes if you own their arrays:
* Enterprise-level SAS drives aren't any more reliable than consumer SATA drives
- But they do have considerably different firmwares that assume they will be placed in an array, and thus have a completely different self-healing scheme than consumer-level drives (generally resulting in higher performance in failure scenarios)
* RAID 5 is a really bad idea - correlated failures are much more likely than the math would indicate, especially with the rebuild times involved with today's huge drives
* You have a lot more filesystem options that might not even make sense to use with a RAID system, like ZFS, as well as other mechanisms for distributing your data at a layer higher than the filesystem
Ultimately the reality is that regardless of the testing you put them under, hard drives will fail, and you need to design your production system around this fact. You *should* burn them in with constant read/write cycles for a couple days in order to identify those drives which are essentially DOA, but you shouldn't assume any drive that passes that process won't die tomorrow.
First of all, I don't know what you're doing building the SPEC tests with GCC on Sparc, since that's hardly a test of optimal performance. Building with the SunPro compiler is not only the right thing to do (shouldn't be hard to believe that Sun's compiler optimizes better for their own hardware), but it also happens to compile just fine on the 1500.
Also, I don't have a lot of respect for someone who claims that WD hard drives are of better quality than Seagate drives. As someone who has killed every WD drive I've ever seen in a real workstation environment, I'll take a Seagate any day, even if it is IDE.
Two important things to remember about the turbo diesel's from VW:
1) Diesel isn't all that easy to find in some parts of the US
2) The emissions from a gallon of diesel are quite a lot worse than a gallon of unleaded, and the process used to refine it is also a lot more polluting.
I have a Treo 300, and its' GPS capability can be used by Palm applications, so the statement that US phones don't offer positioning information to the user is false. Also, for the paranoid, you can disable palm application access to the GPS unit so that AOL can't track you while you're on Instant Messenger... ;-)
You need a NEMA 4X enclosure, like those used in industrial settings. They're fully sealed and can withstand such incidents as being drenched in hydraulic fluid, and being dunked in water.
- corp.com
The main problem you're going to have is possibly overheating, as there is no ventilation since you want to keep the salt out of the system. Cooling is done by raidating heat through the surface of the box, which may not be sufficient for a high power PC. The systems that I've placed in factories and test facilities have typically been much lower power than your average PC, and the individual components were engineered to withstand the harsh environment as well.
Links to companies that build said enclosures:
http://www.hoffmanonline.com
http://www.rittal
I've used both Rittal and Hoffman in the past and been quite pleased with their enclosures and their support. Other companies may be as good, of course, but I haven't worked with them.
The one thing you will probably want to avoid, depending on your environment, is a NEMA 4X keyboard. PC keyboards are cheap, and you will not enjoy using a membrane keyboard for an extended period of time. A salt water environment on a sail boat is nowhere near as harsh as a hydraulic test lab, so your PC keyboard will probably last at least a few months. i think $20-$50 every three months is a cheap price to pay for the comfort of a real keyboard.
>No, MacOS X does not have this feature natively
>implemented.
I don't see anywhere where it says that natively implemented means that it has to be accessible through some sort of nifty clicking in the window. It *IS* natively implemented in the OS, and is a standard property setting in all Quartz-based applications. It's of course left to the application developer whether they allow you to change that setting via the preferences of their application. However, even if they don't, you can use the plist editor (or the command line) to add the property to any native application.
I can't spell either.
s/You\'re/Your/
Well, there you go, now every moron on the planet has puck's NOC list. If this guy *knew* anything from the start, he'd already *have* the NOC list. Basically, if you haven't got the NOC list, you obviously didn't know what you were doing anyhow. Slashdot is *not* the forum for this kind of request. Go to inet-access, or NANOG, and ask for NOC contact information. You're inability to contact their NOC does not mean that everybody on the planet needs to learn about your problem.
If you were to, say, for example, pull your head out of the sand, you would realize a couple of things:
1) It has 2 10/100 ethernet ports
2) It uses PC133 ram
3) Why the heck do you need video on a server?
Sure, IDE means that it isn't for everybody, but farming these things as web servers will be great.
As I said in a previous comment, the quotes are taken out of context. What he actually meant was that they relied on the ISP for physical security of the box, which makes sense. They don't leave an FBI agent there to guard it.
This is reasonable because the ISP shouldn't want anyone else accessing their traffic, and if you're worried about the ISP changing the filter settings, they can already access all of your information anyhow. He's just saying that the box is left at the NOC, and is subject to the same kind of security as the NOC itself.
Ok, I knew that, and I still spelled it wrong. Oops. :-)
(and I just had to get a completely off-topic post in here somewhere, just because I wanna grow up to be an AC someday)
A small company named Enkido was the first to ever offer OC-768 transit, in Manhatten, back in May.
What's even better, if you're talking last mile, you should move to Manhatten, where Enkido has that OC-768 service within 200 feet of *anywhere* on the island (they have 3500 miles of fibre on the island). As with Qwest, they're carrying 40Gbps on a single lamba (wavelength), so they currently peak out at 6.4Tbps, although hopes of ever *routing* that are pretty low at this point.
This is most likely correct. To get a product to market in a timely manner, Microsoft will merely 'carbonate' their app, which is to say that they will remove all calls to deprecated MacOS API's, and use the slimmed down API set known as carbon, which plays nice with OS X.
:-) With Cocoa available on Win32, MacOS X, and GNUStep providing API compatibility on other *nix systems, we would have a truly excellent cross-platform development toolkit. Of course, another strike against this idea is that Microsoft is not likely to want to port Office to Obj-C, and while that isn't the only language that Apple supports, it's a major player.
Microsoft has already produced a Carbon version of IE5 for MacOS X DP4, so that product should actually be quite useable when OS X ships. As for Office, especially from Microsoft, that's probably a fairly, well, huge, codebase.
In any case, what this all means is that *BSD folks are still out in the cold as far as an Office suite from Microsoft. Not that most of them would mind, probably.
However, there is about a snowballs' chance in hell that Microsoft is porting Office to the Cocoa API's, the native MacOS X API. If that were the case, *BSD users would be closer to having a suite, but that would still require a port of parts of CoreFoundation that aren't OpenSource, although a lot of it is. GNUStep might be able to fill in the blanks where CF isn't available.
Why would Microsoft do this? Well, it's *probable* that Apple has quite a bit of Cocoa ported to win32, since that may have been their original plan. Obviously, they've shied away from the win32/x86 crowd at the moment, at least for a full product, probably because of lack of engineering hours to spend on the project, but who knows what else that $150 million deal with Microsoft included.
Of course, the latter part is likely all pipe dream, but it's a nice dream, isn't it?
This is, of course, not unlike British Airways banning Salman Rushdie from flying on their aircraft for fear of an attack on the plane.
Do I think that it's right, in a civil liberties kind of way? I'm not sure. Obviously, it sucks for Mr. Rushdie, and it's not too pleasing for the user who got removed from their ISP, but on the other hand, we have a greater good to consider. (And don't go ranting about me spewing any kind of 'greater good' crap...it's not quite like that).
Realistically, if the ISP is targeted because of the content brought forth by one user (not in violation of any AUP), and, as such, the ISP loses its' connection to the net, or is very congested at the least, the ISP isn't doing anybody any favors by keeping that user. Other users would probably prefer surfing over the possibility of their ISP taking some idealogical stand, and the user in question isn't going to be getting their message out anyhow, given that no one can reach the ISP.
However, we're going to have to draw the line in the sand somewhere. If script kiddies can get opposing or controversial views from being disseminated by denying service to a greater mass of users, that doesn't set a good precedent. It's kind of like the internet equivalent of an economic embargo. We don't like what you stand for, so you're not going to get any packets. Besides, if script kiddies can do it, what's going to stop operatives from world governments doing the same?
Obviously, the real solution here is better cooperation among ISPs so that DoS attacks can be tracked down in a timely manner, and the perpetrators can be dealt with. And now we're back to what seems to be a common issue these days. A great deal of the Evils(tm) of the Internet today could be resolved if service providers would treat each other as equals, as they once did in the NFSNet days (and even in several years after). Granted, they are competitors, and not all ISPs are created equal, but this network doesn't work without cooperation. If we didn't have cooperation, we'd just have a bunch of big WANs that weren't attached to each other.
Let the marketing and sales guys go at each others' throats, but let the tech guys have each others' phone numbers.
Go to Compaq's web site, download the plans, and build one yourself.. :-)
Honestly, though, there aren't any seriously expensive or hard to find components in that device. You might have been able to convince me a few months ago that ARM chips were in short supply, but with the number of companies shipping products based on it going up, I think we would have heard of any production problems.
Realistically, it may just be that Compaq doesn't see a market for it. However, it may not cost them too much more to actually produce and ship it. Obviously, if they don't plan on shipping it, they've already acknowledged that they're going to take a loss on the research and development, so recovering that cost should be a non-issue at this point. The real cost actually comes from advertising/marketing (if they want to seriously push the product) and with production time. These wouldn't be that hard to pump off the line, but that means that they have a production line that isn't producing something else, which perhaps was a more profitable product. There's plenty more random reasons as well (like the PDA market is really heating up and getting seriously competitve at this point, and you can't make a lot of money just on the few gear-heads who buy your product because its' guts are cool). A lot of things have to happen before you can release a product to market.
But, putting all that aside, I've heard that they will be shipping a product around Christmas.
But Konrad filed his patent on August 14, 1997, which pretty much means he's screwed. Even if he *did* invent client/server computing, which I doubt, if more than a year passed between the time which he published a paper and when he filed for the patent, he can't get the patent anymore. This means that even if he did invent it, he could have published a paper about it no earlier than August 14, 1996, and, as we're all aware, there are plenty of previous examples of prior art, dating even back to the 60's, with mainframes and timesharing systems.
If he's really pursing this avenue of 'I own POST and GET', then he's not doing himself any favors. I don't believe that anyone would have percieved his patent to be that broad, and, as such, would never have brought up all this prior art, but since he's going after someone, his entire patent is likely to be thrown out, which certainly isn't what he intended.
This is a standard Cobalt Qube, except I believe that it's black (anybody know for sure? the pic on gateway's site shows it as black, but it might just be black & white). Gateway and Cobalt announced a deal all the way back in October of last year, and this machine has been available for quite some time. Not sure if it made /. the first time around.