It could if you bought a 100% legit unlocked phone overseas, brought it to the US, signed up for service with tethering and then lost it when Apple pulled it away. Or, if you managed to buy your phone outright from AT&T/Apple w/o contract, and lost tethering.
Then again, the number of people who did that are probably too small to be of much interest to the FCC.
Just to let you know... Time Machine over the network is still a little flaky. I wouldn't necessarily trust this as a mechanism for automated backups. You still will probably want to stick to good old fashioned rsync for your backups. You can still setup a cron job (or Launch{Agent|Daemon}) to handle this automatically.
Alternatively, you could patch into the FSEvents framework and roll your own TimeMachine-ish like service.
I wish I could get the last 5 minutes of my life back. That list was bad, but so far no one has included the most telling reason that this list came out of left field... it includes the Phantom lapboard!
Yeah, my local CBS has two sub channels.2 for their 24 hour weather and.3 for a live radar map. I seriously doubt the radar map takes up that much bandwidth, and it's quite handy.
I actually keep my TV tuned to that, just so I can flip from the satellite to the radar quickly.
Or, it's an extra $20 on top of your current voice plan. For me, the extra $20/mo is worth it. I'd go so far as to say that the plans are actually quite reasonable, since they include voice and data.
No, it won't. Each virus has a very specific target that it uses to inject itself into it's host cells, so this will really only benefit HIV or other viruses that have the same attack vector.
Imagine a wall with hundreds of doors on it, each with a different type of lock. Viruses are like burglars trying to break in, but they each only know how to pick one kind of lock. This type of treatment will result in blocking only the doors that have the same type of lock that HIV uses. Hepatitis, for example, would use a very different lock (different wall actually).
Or, since this is slashdot, you could also look at it as a host's firewall. HIV may attack a specific port, and this treatment may block only that port.
This is a very simplistic way of explaining it, but for the most part, this type of treatment only has an effect on HIV's specific attack characteristics. Viruses are usually very particular about what types of cells they attack, and then it can get even more specific. I'd view this as a specific fix.
Now, where things can start to get interesting is if they can manage to generalize this approach to find the appropriate blocking peptides for other types of viruses. If the approach can be generalized, then you might be able to find treatments for other viruses, but the hope for a universal cure for viruses isn't very feasible.
Viruses hijack our own internal machinery to reproduce themselves, so you can't exactly target them the same way that you can bacteria. (There are some common points that are being used to target specific classes of viruses, but I'm not aware of any universal point of attack). You can pretty much target viruses are three points: 1) at the point of infection into the host cell, 2) replication of the virus, 3) at the point where the daughter viruses leave the host cell. The approach mentioned in the article is of type 1.
I have to disagree with you. Form values are sent over the line as strings, and as such, they should be treated as string by the base language/framework. I mean, who's to say that when you enter "3125551212" on a form, that you are talking about an integer number or a phone number string?
As far as SQL injection, every RDMBS access method that I know of allows the developer to execute arbitrary queries. The trick isn't to have automatic SQL escaping (again, the language/framework isn't smart enough to differentiate when my " ' " should really be escaped), but rather to "encourage" the developer to use typed (named) parameters in the SQL.
It isn't the language, it's the dev. More accurately though, since PHP is largely pitched to beginners, it's really the documentation and book authors.
I find the bridge comparison a pretty good one. Bridges are very expensive, so the only way to make them profitable is to make sure that they last a very long time. In order to last a very long time you can't build a bridge on shifting sand... if you do, it will likely be the last bridge you ever build.
If your software is only designed to last a year before rewriting it, then go ahead, build it on "sand" (so to speak). However, if you're designing software for the long term, you better make sure that you're using good solid methods... or else it will eventually fall over like a bridge built on sand.
I got mine Friday too (dev program)... The first thing I did was install xterm and get ssh running. After that, I spent most of my time squinting at the screen trying to read websites. I've had no problems connecting to my cheap Fry's access point with WPA/PSK.
The device itself is pretty interesting. It doesn't actually turn off (unless you explictly tell it to). It doesn't even sleep in the traditional laptop way... it just turns off the screen and wireless (and sends the CPU into a type of sleep mode). That makes turning it back "on" instantaneous... and I like that.
However, I have a few gripes with it. The screen (beautiful as it is), I think is actually too small. The screen is too small to hold the device at a comfortable distance away and actually read a website. You have to zoom the browser just to be able to read the text (at a comfortable distance). (Disclaimer: I am under 30 and wear glasses, so my vision isn't the problem). Also, there is no scroll wheel. This means that in order to scroll in Opera, you have to take the stylus (which is uncomfortable in and of itself) and click and drag the screen. With only a limited screen height, reading slashdot can be painful... more so than usual. The main buttons are also a little small, and force your hand into an awkward angle to use them. The directional pad is also blocked by the screen cover, so that makes clicking the left arrow a little difficult to use.
Also, there is not enough RAM on the device. Reading a website like ESPN (lots of flash and graphics) will cause the device to slow down and display "Low memory" warnings. However, GMail works like a charm...
I would have also liked to have seen a CF slot. My digital camera uses CF cards, and this would have made a great platform for viewing pictures. But this also goes back to the size... they went small and didn't have room for anything more than an RS-MMC.
Final gripe: wireless is great for one location, but there is no easy way to configure the device to work in multiple locations. You can define wireless networks and wep/wsa-psk codes for each network, but there is no way to easy switch between them. For example, I have it configured to auto-connect to my home network. When I go to work, it has to try to connect to my home network, fail, and then I can select which access point I'd like to try to connect to. Also, there isn't support for VPN connections, which makes my campus wireless access (PPTP) impossible.
Overall, the 770 is a good little device. In fact, I have to steal it back from my wife at times (it includes a Mahjong game)... It has a good interface (modified gnome/gtk), and connectivity is good. However, it is too small to be useful as a good internet tablet at home. The size is a bonus in that it is easily portable, but the difficulty in switching between networks makes travelling (and using 802.11 connectivity) harder than it should be. I also like the fact that you can attach the 770 to your main computer and it appear as a usb flash drive... this definitely makes getting files onto the device easy.
There is a lot to like, and a lot to not like. If you get one, just know the limitations and you'll be happy. After playing with mine for a few days, I'm not sure I would not have bought one at retail price... to tell you the truth, I'm not sure I would have paid the developer's price either... This is a good first effort by Nokia, and their software deisgn is actually very good. They just need to work on the hardware design... I hope that the 2006 software update fixes the problems with configuration, but that isn't going to change the hardware issues.
You do realize what sudo means right? <hint> do the following as the super user (root) </hint>
So, yes, it is quite possible to run things as root on distros that don't give you direct access to the root account. This is also true of Mac OS X as well... anytime you sudo, for all practical purposes, you are root... no login required.
Now granted, it is safer than just loging in as root, but since you still have to install things with sudo (root), there is still a risk.
The decentralized nature of this is the problem. It is impossible to securely authenticate a person using an untrusted server.
If you ran one, you'd have only your authentication information stored on your server. Then, to authenticate to a remote server, you'd point that server to your server. The remote server would ask your server who you are, and then authenticate you (log you in). The biggest thing is that the remote server has to trust that what your server tells it is correct.
This may have a place in the blog world, where you're mainly looking for an easy way to keep your user profile the same across many blogs, but certainly not anywhere where you'd have sensitive data.
Another point, this is supposed to be authentication and not authorization. But actually, this isn't really authentication either... The difference between the two is really the question the server is asking. In authentication, the question is "are you who you say you are?". In authorization the question is "do I have the rights to perform a task?". With OpenID, the question is "who are you?". There is no verification to see if you are who you say you are (from the remote server's perspective, since there is no trust between servers), so you aren't actually authenticated.
It would be up to your server to determine what rights an open-id authenticated user would have.
That's not the point... If you go to Oregon, or Nevada, or California, or anywhere in the country, and buy a car, and bring it back to CA to register it, you have to pay taxes... As opposed to only being able to buy a car in California. So long as the law is enforced equally wrt in- and out- of state commerce, there isn't a problem.
Actually, no... they were right. Aside from the fact that they are the Supreme Court, the issue was various states' laws about the interstate sale of alcohol. It didn't have a thing to do the with Internet per se... even if the Internet will be the major vehicle for such sales. Those laws allowed for intrastate sales, but not those from out of state. Only Congress has the power to regulate interstate commerce (not the states), as such those laws were ruled to be discriminatory and protectionist.
And since we live in a country where things are legal unless they are made illegal by a law, when the law is overturned, those sales are now legal.
Agreed... You can use callback IFRAMES to generate a lot of the same functionality as AJAX. You don't actually need the XML results to do the work, hidden iframes work just as well. They can also be more flexible, since you can embed javascript in the hidden frame to make a callback to the parent. The only down side is if the user is too "click-happy". You may not have time to load the hidden iframe's page...
I don't know exactly if/how AJAX style XML requests get around this.
There are plenty of planes that don't have hydraulic systems associated with a control stick, and there are a lot more that have systems no more complicated than what's in a car. There's no reason a hydraulic-assist stick, much like today's power steering, couldn't be developed for use in a car.
Yes, and it is easier to move a control surface that isn't under 3 tons of metal. If you were to use a stick with a car, you'd have to rotate the tires working against the weight of the car, friction, etc... With a plane you are really only moving control surfaces in the air (with air resistance at speed, but still...)
I'm loathe to reply to anything that equates traffic weight laws to slavery, but here goes...
Opinionated as that article may be, there is a good point. No one is saying get rid of SUVs. But they do cause greater damage to roads than a smaller car, and as such they should have to compensate for that somehow... whether that be by not driving on those streets or by paying a higher tax.
You can't have your cake and eat it too... either take the tax cut, and avoid driving by my already pot-holed street or pay for the extra up keep.
It isn't inherently limited to Macs... however, the only computers that they have written the client for is Mac 10.2.8 or better.
(From the FAQ)
Q: Can I use Xgrid with other UNIX-based computers?
A: The short answer is no.
The long answer is that Xgrid uses an XML property list protocol built on top of BEEP for all of its inter-computer communication and coordination, and because these protocols are open, it is possible a client, agent, or controller could be written to run on other UNIX-based computers and interoperate with Xgrid. However, no such programs have been written.
What I wonder is if the estate of Buster Keaton could sue Disney for copyright violations. If Steamboat Willie ripped off Steamboat Bill, then why wasn't Disney at the wrong end of a piracy law suit?
The problem was the handling of the extension. The extension is retroactive. That is the part that they ruled constitutional.
The upside to the media companies is that in another 20 years, they can lobby for another 20 year extension and it too will be constitutional. And then repeat that forever.
It means that the media companies don't have to give anything back to the public, if they lobby well enough. The Constitution says that congress can define how long the terms of copyrights are for. This basically means that they can make it a ludicrous amount of time.
Re:Drive reliability/backups are major factors
on
IDE RAID Examined
·
· Score: 1
We went with a 3-ware IDE RAID simply for the reason that they are cheap and easy. It is much easier to get a PI to agree to a $7000 IDE-RAID server over a $20000 SCSI one.
We've had some problems with drives going out, but part of that was cabling (you really have to have a case that suits short cable length). The other part was drives 'faking' being sick. If a drive is called 'bad', we first have to check to see if the drive is really bad. The controller we have (3ware 6800) is really touchy.
The problem is, when I had the controller decide to go on vacation one day eariler in the year, it was a bitch to get back working. Backups are really hard. Thank God we have a huge MDSS system at my school (150 TB at last recollection).
I think my next recommendation is to get another mirrored system just to avoid such problems. You really do need two systems. And some sort of other backup... I thought tap would cut it, but alas... um... no.
Slashdot Mirror
It could if you bought a 100% legit unlocked phone overseas, brought it to the US, signed up for service with tethering and then lost it when Apple pulled it away. Or, if you managed to buy your phone outright from AT&T/Apple w/o contract, and lost tethering.
Then again, the number of people who did that are probably too small to be of much interest to the FCC.
Just to let you know... Time Machine over the network is still a little flaky. I wouldn't necessarily trust this as a mechanism for automated backups. You still will probably want to stick to good old fashioned rsync for your backups. You can still setup a cron job (or Launch{Agent|Daemon}) to handle this automatically.
Alternatively, you could patch into the FSEvents framework and roll your own TimeMachine-ish like service.
Yes it's true. The EPA guy man has no dick.
Didn't you see Superman 2? A nuclear explosion in space could send super villains to enslave us all!
I wish I could get the last 5 minutes of my life back. That list was bad, but so far no one has included the most telling reason that this list came out of left field... it includes the Phantom lapboard!
That was actually a nice service... I've used their web site for years, but didn't know about this.
That was a nice surprise.
Yeah, my local CBS has two sub channels .2 for their 24 hour weather and .3 for a live radar map. I seriously doubt the radar map takes up that much bandwidth, and it's quite handy.
I actually keep my TV tuned to that, just so I can flip from the satellite to the radar quickly.
Or, it's an extra $20 on top of your current voice plan. For me, the extra $20/mo is worth it. I'd go so far as to say that the plans are actually quite reasonable, since they include voice and data.
No, it won't. Each virus has a very specific target that it uses to inject itself into it's host cells, so this will really only benefit HIV or other viruses that have the same attack vector.
Imagine a wall with hundreds of doors on it, each with a different type of lock. Viruses are like burglars trying to break in, but they each only know how to pick one kind of lock. This type of treatment will result in blocking only the doors that have the same type of lock that HIV uses. Hepatitis, for example, would use a very different lock (different wall actually).
Or, since this is slashdot, you could also look at it as a host's firewall. HIV may attack a specific port, and this treatment may block only that port.
This is a very simplistic way of explaining it, but for the most part, this type of treatment only has an effect on HIV's specific attack characteristics. Viruses are usually very particular about what types of cells they attack, and then it can get even more specific. I'd view this as a specific fix.
Now, where things can start to get interesting is if they can manage to generalize this approach to find the appropriate blocking peptides for other types of viruses. If the approach can be generalized, then you might be able to find treatments for other viruses, but the hope for a universal cure for viruses isn't very feasible.
Viruses hijack our own internal machinery to reproduce themselves, so you can't exactly target them the same way that you can bacteria. (There are some common points that are being used to target specific classes of viruses, but I'm not aware of any universal point of attack). You can pretty much target viruses are three points: 1) at the point of infection into the host cell, 2) replication of the virus, 3) at the point where the daughter viruses leave the host cell. The approach mentioned in the article is of type 1.
I have to disagree with you. Form values are sent over the line as strings, and as such, they should be treated as string by the base language/framework. I mean, who's to say that when you enter "3125551212" on a form, that you are talking about an integer number or a phone number string?
As far as SQL injection, every RDMBS access method that I know of allows the developer to execute arbitrary queries. The trick isn't to have automatic SQL escaping (again, the language/framework isn't smart enough to differentiate when my " ' " should really be escaped), but rather to "encourage" the developer to use typed (named) parameters in the SQL.
It isn't the language, it's the dev. More accurately though, since PHP is largely pitched to beginners, it's really the documentation and book authors.
I find the bridge comparison a pretty good one. Bridges are very expensive, so the only way to make them profitable is to make sure that they last a very long time. In order to last a very long time you can't build a bridge on shifting sand... if you do, it will likely be the last bridge you ever build.
If your software is only designed to last a year before rewriting it, then go ahead, build it on "sand" (so to speak). However, if you're designing software for the long term, you better make sure that you're using good solid methods... or else it will eventually fall over like a bridge built on sand.
You're new here, aren't you? : )
Sorry, as far as I can tell there is no way to flip the screen...
I got mine Friday too (dev program)... The first thing I did was install xterm and get ssh running. After that, I spent most of my time squinting at the screen trying to read websites. I've had no problems connecting to my cheap Fry's access point with WPA/PSK.
The device itself is pretty interesting. It doesn't actually turn off (unless you explictly tell it to). It doesn't even sleep in the traditional laptop way... it just turns off the screen and wireless (and sends the CPU into a type of sleep mode). That makes turning it back "on" instantaneous... and I like that.
However, I have a few gripes with it. The screen (beautiful as it is), I think is actually too small. The screen is too small to hold the device at a comfortable distance away and actually read a website. You have to zoom the browser just to be able to read the text (at a comfortable distance). (Disclaimer: I am under 30 and wear glasses, so my vision isn't the problem). Also, there is no scroll wheel. This means that in order to scroll in Opera, you have to take the stylus (which is uncomfortable in and of itself) and click and drag the screen. With only a limited screen height, reading slashdot can be painful... more so than usual. The main buttons are also a little small, and force your hand into an awkward angle to use them. The directional pad is also blocked by the screen cover, so that makes clicking the left arrow a little difficult to use.
Also, there is not enough RAM on the device. Reading a website like ESPN (lots of flash and graphics) will cause the device to slow down and display "Low memory" warnings. However, GMail works like a charm...
I would have also liked to have seen a CF slot. My digital camera uses CF cards, and this would have made a great platform for viewing pictures. But this also goes back to the size... they went small and didn't have room for anything more than an RS-MMC.
Final gripe: wireless is great for one location, but there is no easy way to configure the device to work in multiple locations. You can define wireless networks and wep/wsa-psk codes for each network, but there is no way to easy switch between them. For example, I have it configured to auto-connect to my home network. When I go to work, it has to try to connect to my home network, fail, and then I can select which access point I'd like to try to connect to. Also, there isn't support for VPN connections, which makes my campus wireless access (PPTP) impossible.
Overall, the 770 is a good little device. In fact, I have to steal it back from my wife at times (it includes a Mahjong game)... It has a good interface (modified gnome/gtk), and connectivity is good. However, it is too small to be useful as a good internet tablet at home. The size is a bonus in that it is easily portable, but the difficulty in switching between networks makes travelling (and using 802.11 connectivity) harder than it should be. I also like the fact that you can attach the 770 to your main computer and it appear as a usb flash drive... this definitely makes getting files onto the device easy.
There is a lot to like, and a lot to not like. If you get one, just know the limitations and you'll be happy. After playing with mine for a few days, I'm not sure I would not have bought one at retail price... to tell you the truth, I'm not sure I would have paid the developer's price either... This is a good first effort by Nokia, and their software deisgn is actually very good. They just need to work on the hardware design... I hope that the 2006 software update fixes the problems with configuration, but that isn't going to change the hardware issues.
I'd give it a 6/10.
You do realize what sudo means right?
<hint>
do the following as the super user (root)
</hint>
So, yes, it is quite possible to run things as root on distros that don't give you direct access to the root account. This is also true of Mac OS X as well... anytime you sudo, for all practical purposes, you are root... no login required.
Now granted, it is safer than just loging in as root, but since you still have to install things with sudo (root), there is still a risk.
If you ran one, you'd have only your authentication information stored on your server. Then, to authenticate to a remote server, you'd point that server to your server. The remote server would ask your server who you are, and then authenticate you (log you in). The biggest thing is that the remote server has to trust that what your server tells it is correct.
This may have a place in the blog world, where you're mainly looking for an easy way to keep your user profile the same across many blogs, but certainly not anywhere where you'd have sensitive data.
Another point, this is supposed to be authentication and not authorization. But actually, this isn't really authentication either... The difference between the two is really the question the server is asking. In authentication, the question is "are you who you say you are?". In authorization the question is "do I have the rights to perform a task?". With OpenID, the question is "who are you?". There is no verification to see if you are who you say you are (from the remote server's perspective, since there is no trust between servers), so you aren't actually authenticated.
It would be up to your server to determine what rights an open-id authenticated user would have.
That's not the point... If you go to Oregon, or Nevada, or California, or anywhere in the country, and buy a car, and bring it back to CA to register it, you have to pay taxes... As opposed to only being able to buy a car in California. So long as the law is enforced equally wrt in- and out- of state commerce, there isn't a problem.
Actually, no... they were right. Aside from the fact that they are the Supreme Court, the issue was various states' laws about the interstate sale of alcohol. It didn't have a thing to do the with Internet per se... even if the Internet will be the major vehicle for such sales. Those laws allowed for intrastate sales, but not those from out of state. Only Congress has the power to regulate interstate commerce (not the states), as such those laws were ruled to be discriminatory and protectionist.
And since we live in a country where things are legal unless they are made illegal by a law, when the law is overturned, those sales are now legal.
Agreed... You can use callback IFRAMES to generate a lot of the same functionality as AJAX. You don't actually need the XML results to do the work, hidden iframes work just as well. They can also be more flexible, since you can embed javascript in the hidden frame to make a callback to the parent. The only down side is if the user is too "click-happy". You may not have time to load the hidden iframe's page...
I don't know exactly if/how AJAX style XML requests get around this.
I'm loathe to reply to anything that equates traffic weight laws to slavery, but here goes...
Opinionated as that article may be, there is a good point. No one is saying get rid of SUVs. But they do cause greater damage to roads than a smaller car, and as such they should have to compensate for that somehow... whether that be by not driving on those streets or by paying a higher tax.
You can't have your cake and eat it too... either take the tax cut, and avoid driving by my already pot-holed street or pay for the extra up keep.
It isn't inherently limited to Macs... however, the only computers that they have written the client for is Mac 10.2.8 or better.
(From the FAQ)
Q: Can I use Xgrid with other UNIX-based computers?
A: The short answer is no.
The long answer is that Xgrid uses an XML property list protocol built on top of BEEP for all of its inter-computer communication and coordination, and because these protocols are open, it is possible a client, agent, or controller could be written to run on other UNIX-based computers and interoperate with Xgrid. However, no such programs have been written.
What I wonder is if the estate of Buster Keaton could sue Disney for copyright violations. If Steamboat Willie ripped off Steamboat Bill, then why wasn't Disney at the wrong end of a piracy law suit?
Just a thought...
Read the history of the story.
The problem was the handling of the extension. The extension is retroactive. That is the part that they ruled constitutional.
The upside to the media companies is that in another 20 years, they can lobby for another 20 year extension and it too will be constitutional. And then repeat that forever.
It means that the media companies don't have to give anything back to the public, if they lobby well enough. The Constitution says that congress can define how long the terms of copyrights are for. This basically means that they can make it a ludicrous amount of time.
We went with a 3-ware IDE RAID simply for the reason that they are cheap and easy. It is much easier to get a PI to agree to a $7000 IDE-RAID server over a $20000 SCSI one.
We've had some problems with drives going out, but part of that was cabling (you really have to have a case that suits short cable length). The other part was drives 'faking' being sick. If a drive is called 'bad', we first have to check to see if the drive is really bad. The controller we have (3ware 6800) is really touchy.
The problem is, when I had the controller decide to go on vacation one day eariler in the year, it was a bitch to get back working. Backups are really hard. Thank God we have a huge MDSS system at my school (150 TB at last recollection).
I think my next recommendation is to get another mirrored system just to avoid such problems. You really do need two systems. And some sort of other backup... I thought tap would cut it, but alas... um... no.