This is exactly what Bluetooth is for: standardized radio communication between small devices with the encryption built in to the standard. Wires that tie you to an unhealthy position should be removed.
(3) Court orders authorizing disclosure under subparagraph (C) shall issue only with
prior notice to the consumer and only if the law enforcement agency shows that there is probable cause to believe that the records or other information sought are relevant to a legitimate law enforcement inquiry.
Of course, IANAL, but that's the part I meant. The FBI should have to first inform everyone who visited IMC that they would be going after the records. The search should be seen not as one of IMC, but as one of each visitor to the site. If the FBI can't justify searching all of those people, then they shouldn't be able to subpoena the entire logs.
It's similar to carnivore: they can't read everyone's email and say they're throwing away all but the criminals'. They have to be held to stricter protections against unlawful search and seizure.
And of course, the inevitable law will probably not protect the people, but the ease of the FBI's search.
But the point here is that in trying to find the poster, they might be able to find the identities of anyone who visited the site just to read their news.
IANAL and what not, but the Video Privacy Protection Act that I mentioned above says that the authorities must notify the one person whose records they're seeking and then seek just that one person's records. They can't ask the store to turn over a list of all their cutomers and what each of them rented.
Hopefully, a similar law can be worked out for net traffic. If the host/ISP cannot return records subpoenaed for just one user, then they should not be made to return overly broad records. Unfortunately, the inevitable law will probably be just the opposite.
1) turn over server logs containing the IP address of the alleged lawbreaker
This does not seem reasonable. In their statement the IMC makes a good point that turning over the entire log(s) would expose more IP addresses than just the lawbreaker's. This could be seen as intimidating people from visiting their site just to read it.
how do they plan on bandaging a wound for a newly found vulnerabilty that has yet been exposed to the security community as a whole? Do they expect their system to just guess on its own?
I think that's the general idea. Keeping patches up to date is almost autmatic as it is, just watch for those emails from RedHat. The next step is to teach the system to be able to tell the difference between legitimate and illegitimate access. Not an easy task, to be sure, but people have been working on it for a while.
You're right about the help desk staff for sure. I guess you'd have to provide tiers of support. Like those non-funny signs in auto shops that list increasing rates depending on whether you wait, watch, or help out.
"The more you want to fuck it up on your own, the more you'll pay to have it unfucked"--even to the point where it would have been cheaper to hire your (the vendor's) programmer/consultants in the first place. You'll just have to be OK with leaving that decision in the hands of your customer.
Your responsibility to provide support should end the moment the product's source code is tampered with by a customer. You can't be held responsible for what they do...
While that's true, degrees of support are by no means fixed. In some ways, not supporting open source code if it's been modified is like Gateway's voiding warranties on boxes where the user installed new software. Maybe the client is choosing your open source based solution because they want to be able to tweak some code.
I don't think you should cut them off entirely. You'll just need more skilled support staff who can determine whether new changes are causing their problems, and if those new changes fall within the scope of your support.
I think thats was why they put the little ? link to everything2.
I mean, I know it's already expecting too much of the avg/. reader to read the linked story (before posting), but I think the linked summary is reasonable...
Having worked on WAP and wireless data, having faster data rates will significantly improve wireless services. For example, right now WAP developers have to divide the data into decks, because of the 14,4 data rate limitation.
Actually, the data rate is 9.6. And developers don't "have to" do shit. Don't mean to harp on them, but, as the cliche goes, it's a poor craftsman who blames his tools. Imode runs at 9.6 too and it's the most popular ISP in Japan at all--over wireline ISPs. If "developers," which here I take to mean content providers, were more creative they'd do more with what they've got.
Actually, CDMA networks are up and running all over. Sprint and Verizon are the nations largest CDMA operators. What you're thinking of is either 1XRTT, CDMA2000, or W-CDMA (aka UMTS). 1XRTT is a so-called 2.5G tech (don't be fooled by Qualcomm all of a sudden calling it 3G). CDMA200 and W-CDMA are competing standards for 3G. W-CDMA is winning by a longshot.
And while I'm here, GPRS is the 2.5G transition technology for TDMA and GSM.
As bad as this sounds, if you're renting something you don't own it. If the company from whom you're renting goes under, you are no longer renting from them and don't get to use whatever you were renting.
Your best bet is to buy, not rent. And if a company will only rent to you, start one that sells what they're renting. You'll have a market. (On/. at least.)
Well, it helps current security just like he said: you're always patched against the last attack. But then it opens up all sorts of new security questions at the same time.
Ultimately, if you can get pieces of applications delivered to you--and saved--then updated when you need them, you'll be better off. How much nicer is it to use something like Red Carpet to keep everything you have up to date and to manage installs and uninstalls?
Where I think it will outshine the "network computer" model is when you top it off with a little (duck the buzzword) P2P. Then you can get software (as a service or not) from anyone, as well as providing it. Kind of like open source, only "open functionality" or something that doesn't sound so stupid. I'm going to stop before this hole gets too deep, but I hope you know what I mean.
but at least throw in a sentence so it "seems" like you are really replying.
No way man, this is/. I don't want to insult anyone's intelligence... and actually I just clicked the wrong "reply". So many links... So much black green, where am I...
Fortunately, the future of the desktop is not in the 1980's applications that required you to load the application yourself, run it, back it up, and otherwise play sys-admin to your own computer. The future of the desktop will be using Internet appliances where the applications will sit out on the net (or your corporate Intranet) and you just download the small pieces that allow you to use those applications without having to take responsibility for them
So here's someone from Redhat extolling software provided over the network, a la Windows XP. What does everyone who screamed bloody murder two days ago want to say now?
(And, for the record, I personally am a fan of this new model for software--from a software architecture standpoint.)
When I saw Bill Joy speak at Columbia in the fall he said this had happened to him. Eventually, they found out which ethernet cable belonged to the errant server (from the switch) and followed it around the room. The machine turned out to be underneath the elevated floor.
I think you're getting things a little muddled. We can leave out HTTP POST. XML-RPC and SOAP use HTTP, and can use other transport protocols.
Looking at just on the data mark-up, if you're parsing for "data1\tdata2\t\n" and the feed is changed to "data1\tdata3\tdata4\tdata2\t\n" you're free to ignore the "new" fields, but you're app will have "data3" where it wants "data2". (And of course this assumes you we're parsing from left to right, which is by no means given.)
Not true. You'll still have to rewrite your app to take into account the new field. If you are going to rewrite it anyway then what have you gained?
You can rewrite it at your convenience, or not at all if you don't care about the new fields.
It's like this: what if the w3c suddenly recommended the blink tag all around? Would you rush to download a new version of your browser that supports it? If you don't care, then it doesn't matter. Your existing browser will ignore the new tag, but still correctly interpret all the old ones.
Can someone explain why I would choose XML-RPC or SOAP for an xplat / xlang distributed app as opposed to CORBA? Is the main purpose for using HTTP as the transport just a way to make it traverse firewalls and/or to traverse proxy servers?
Because CORBA is a royal pain in the ass to implement. And if there's no ORB with bindings for your favorite language/platform, well, you'll have to extend your deadline as long as you think it'll take you to write one. For quick (and/or dirty) XML-RPC is definitely easier. SOAP is a bit trickier and poses more competition to something like CORBA.
Really, it's unfair to call these technologies competitors. Without C++ there wouldn't be Java, and without CORBA their wouldn't be SOAP.
whatever. xml doesn't make that necessarily any easier or more likely than any other alternative.
Good point. But, XML seems to be the alternative that people have settled on. So...
And I think your stock quote app was a good enough example. Say you feed it a ticker symbol and get back price and time of last trade. The the quote provider gets generous and starts serving price, price at last close, time of last trade, and volume. If they change the order, your tab-parsing routine breaks. If they just add XML tags, in whatever order, your app will just look for the ones it wants and ignore the rest. Ideally, that is.
But fundamentally you're right, if we all agreed to parse tab-delimited files left to right, top to bottom, they'd be easy enough to use.
Where it gets more interesting is with stuff like RDF, where an app that doesn't even know what tags to look for can read a document+schema and begin inferring facts about it.
i'd love to see an xml-rpc application as useful as that. and then for someone to explain why wrapping it all in xml makes it better.
Because then they can add new information (new fields or whatever), which would change the format of the document, without breaking all the apps that rely on their feed.
It is HTTP POST. Or GET. Or maybe SMTP if you wanted it that way. The New York Times is not the best place from which to arm yourself for technical retorts. Remember all those AC's thinking they'd out-smarted Michael Rabin based on the math in the NYT?
Slashdot Mirror
This is exactly what Bluetooth is for: standardized radio communication between small devices with the encryption built in to the standard. Wires that tie you to an unhealthy position should be removed.
Of course, IANAL, but that's the part I meant. The FBI should have to first inform everyone who visited IMC that they would be going after the records. The search should be seen not as one of IMC, but as one of each visitor to the site. If the FBI can't justify searching all of those people, then they shouldn't be able to subpoena the entire logs.
It's similar to carnivore: they can't read everyone's email and say they're throwing away all but the criminals'. They have to be held to stricter protections against unlawful search and seizure.
And of course, the inevitable law will probably not protect the people, but the ease of the FBI's search.
IANAL and what not, but the Video Privacy Protection Act that I mentioned above says that the authorities must notify the one person whose records they're seeking and then seek just that one person's records. They can't ask the store to turn over a list of all their cutomers and what each of them rented.
Hopefully, a similar law can be worked out for net traffic. If the host/ISP cannot return records subpoenaed for just one user, then they should not be made to return overly broad records. Unfortunately, the inevitable law will probably be just the opposite.
This does not seem reasonable. In their statement the IMC makes a good point that turning over the entire log(s) would expose more IP addresses than just the lawbreaker's. This could be seen as intimidating people from visiting their site just to read it.
It would seem we need something akin to the Video Privacy Protection Act for internet traffic.
I think that's the general idea. Keeping patches up to date is almost autmatic as it is, just watch for those emails from RedHat. The next step is to teach the system to be able to tell the difference between legitimate and illegitimate access. Not an easy task, to be sure, but people have been working on it for a while.
"The more you want to fuck it up on your own, the more you'll pay to have it unfucked"--even to the point where it would have been cheaper to hire your (the vendor's) programmer/consultants in the first place. You'll just have to be OK with leaving that decision in the hands of your customer.
While that's true, degrees of support are by no means fixed. In some ways, not supporting open source code if it's been modified is like Gateway's voiding warranties on boxes where the user installed new software. Maybe the client is choosing your open source based solution because they want to be able to tweak some code.
I don't think you should cut them off entirely. You'll just need more skilled support staff who can determine whether new changes are causing their problems, and if those new changes fall within the scope of your support.
You'll have to make some new rules here.
Here's some food: Imipolex-G doesn't exist outside of Gravity's Rainbow. Please refer to a chapter in this book.
I mean, I know it's already expecting too much of the avg /. reader to read the linked story (before posting), but I think the linked summary is reasonable...
Actually, the data rate is 9.6. And developers don't "have to" do shit. Don't mean to harp on them, but, as the cliche goes, it's a poor craftsman who blames his tools. Imode runs at 9.6 too and it's the most popular ISP in Japan at all--over wireline ISPs. If "developers," which here I take to mean content providers, were more creative they'd do more with what they've got.
And while I'm here, GPRS is the 2.5G transition technology for TDMA and GSM.
So, to get your wireless acronyms straight:
2G------->2.5G------->3G
gsm------>gprs------>umts(w-cdma)
tdma---->(ditto)------>(ditto)
cdma---->1Xrtt----->?(poss. cdma2000)
Your best bet is to buy, not rent. And if a company will only rent to you, start one that sells what they're renting. You'll have a market. (On /. at least.)
Ultimately, if you can get pieces of applications delivered to you--and saved--then updated when you need them, you'll be better off. How much nicer is it to use something like Red Carpet to keep everything you have up to date and to manage installs and uninstalls?
Where I think it will outshine the "network computer" model is when you top it off with a little (duck the buzzword) P2P. Then you can get software (as a service or not) from anyone, as well as providing it. Kind of like open source, only "open functionality" or something that doesn't sound so stupid. I'm going to stop before this hole gets too deep, but I hope you know what I mean.
No way man, this is /. I don't want to insult anyone's intelligence... and actually I just clicked the wrong "reply". So many links... So much black green, where am I...
Please mod this down.
Er, .NET. I mean .NET.
So here's someone from Redhat extolling software provided over the network, a la Windows XP. What does everyone who screamed bloody murder two days ago want to say now?
(And, for the record, I personally am a fan of this new model for software--from a software architecture standpoint.)
When I saw Bill Joy speak at Columbia in the fall he said this had happened to him. Eventually, they found out which ethernet cable belonged to the errant server (from the switch) and followed it around the room. The machine turned out to be underneath the elevated floor.
Yes, they have to answer simultaneously. Answering in succession would constitute communication between players, which is disallowed.
Looking at just on the data mark-up, if you're parsing for "data1\tdata2\t\n" and the feed is changed to "data1\tdata3\tdata4\tdata2\t\n" you're free to ignore the "new" fields, but you're app will have "data3" where it wants "data2". (And of course this assumes you we're parsing from left to right, which is by no means given.)
If you're so far gone you use VB, then why choose CORBA over DCOM?
But seriously, 15 exhausting seconds of Googling failed to turn up a serious CORBA works for Standard ML. (But it's good to see there's one for Lisp).
You can rewrite it at your convenience, or not at all if you don't care about the new fields.
It's like this: what if the w3c suddenly recommended the blink tag all around? Would you rush to download a new version of your browser that supports it? If you don't care, then it doesn't matter. Your existing browser will ignore the new tag, but still correctly interpret all the old ones.
Because CORBA is a royal pain in the ass to implement. And if there's no ORB with bindings for your favorite language/platform, well, you'll have to extend your deadline as long as you think it'll take you to write one. For quick (and/or dirty) XML-RPC is definitely easier. SOAP is a bit trickier and poses more competition to something like CORBA.
Really, it's unfair to call these technologies competitors. Without C++ there wouldn't be Java, and without CORBA their wouldn't be SOAP.
(Please no language wars. They all suck.)
Good point. But, XML seems to be the alternative that people have settled on. So...
And I think your stock quote app was a good enough example. Say you feed it a ticker symbol and get back price and time of last trade. The the quote provider gets generous and starts serving price, price at last close, time of last trade, and volume. If they change the order, your tab-parsing routine breaks. If they just add XML tags, in whatever order, your app will just look for the ones it wants and ignore the rest. Ideally, that is.
But fundamentally you're right, if we all agreed to parse tab-delimited files left to right, top to bottom, they'd be easy enough to use.
Where it gets more interesting is with stuff like RDF, where an app that doesn't even know what tags to look for can read a document+schema and begin inferring facts about it.
Because then they can add new information (new fields or whatever), which would change the format of the document, without breaking all the apps that rely on their feed.
It is HTTP POST. Or GET. Or maybe SMTP if you wanted it that way. The New York Times is not the best place from which to arm yourself for technical retorts. Remember all those AC's thinking they'd out-smarted Michael Rabin based on the math in the NYT?