Seriously, this is no moral question. "Poisoning" Storm is nothing but a good idea. Unless there's a problem with the command you send out and it completely wipes the end users hard drive and all their personal data or does something else destructive to the infected user. Which the original bot might easily have done.
By the time a user is participating in a botnet, they are a lost cause. If you want to help them, fine, but do it before they get infected.
And anyone who doesn't do backups WILL lose data, it's only a question of when.
I realize that I'm one of probably fifteen or twenty threads here, but it looks like people are still coming up with all kinds of inventive ways around the fact that it is an untrusted terminal. Untrusted means anything you do on that terminal is subject to being messed with.
Most of the smarter methods revolve around authentication -- one-time-pads, etc. That'll protect you from a keylogger, but what about a pwned web browser? And yes, you run yours off the USB device -- suppose the whole OS is pwned, and injects screen-scraping-logging into your USB web browser. Worse, suppose it mods the EXE to contain itself, so that even if you never get hit, you're a carrier -- the next time you open it at another internet cafe, you'll infect them.
Then there are the stupid methods -- copy/paste, drag characters around, character map, etc. That's an OK skill to have when your keyboard breaks -- just recently, Ubuntu decided my Apple USB keyboard is a Macbook keyboard, so numlock would kill half my keyboard until I restarted X. But this kind of only-use-the-mouse mentality is pointless on a public terminal -- fine, you've defeated most hardware keyloggers, and you've defeated the dumber software ones. The smarter one saw you click a button, or hit enter, and grabbed the value of the form element at that point.
The closest I can think of to something that might work is to boot from a livecd, AND use the mouse for everything. In which case, you're still vulnerable to screen capture (grab an image on every mouse click, say), and to things like the Blue Pill proof-of-concept -- what makes you think it's actually booting your livecd on bare metal, and not in some virtual machine?
For all the effort you would spend thinking up schemes like these, and slowly realizing how they can be defeated, it's probably easier just to buy an EEE PC. Control the endpoint, and problem solved, barring insanely difficult and unreliable schemes like tempest. (There was even one which could figure out your password by listening to your keystrokes.)
I'm not sure I really see the point -- if you're carrying around a PDA anyway, get a beefier one, get wireless on it, and use that. Control your endpoints.
That said, you could go to the other extreme and commoditize it -- PayPal will sell you a hardware key for $5 or so, which generates pseudorandom number every 30 seconds or so. This same key can be used with VeriSign's OpenID service. It'd probably cost a bit more to put it entirely under your control -- so that you're the one who initializes the key, and you're entering it into your own server, not PayPal's or VeriSign's -- but the idea is the same.
The obvious difference is, with your own real endpoint, you can actually work with private data. What the key buys you on a public terminal is the knowledge that if they didn't do anything to your account by the time you log out, you're safe. But you're still vulnerable to things like session hijacking and simple logging -- at the very least, they could capture the screen at intervals.
My answer? Never use WiFi at a hotel, airport, or public terminal, suck it up and pay the $60 a month for EVDO to know and control your access point security. Ok, that is a pretty horrible solution. Is EVDO actually more secure? What's stopping someone from intercepting it? Admittedly, I know nothing about its actual implementation, so I don't know if it's doing crypto.
But seriously, why not https, a VPN, something like that? I don't imagine EVDO is going to be as fast or as reliable as wifi, wherever the wifi is available.
Yes, some applications can easily be proprietary. It's even possible to argue that some applications can only reasonably be made proprietary -- cases where security-through-obscurity is a necessity of the problem space, and there's not a lot you can do about it. (MMOs come to mind.)
The Flash Player is not something which should be proprietary. It is the exact polar opposite of something which should be proprietary.
What I find ironic is that what many people see as indispensable are the authoring tools, yet you are free to actually go and read the Flash spec for those. The only thing you are not allowed to do is both read the spec and create a player from it.
Some elements of this problem could be solved by having backup servers use wireless and filesharing protocols that might stand the test of time- e.g., 802.11n and SAMBA. No need to just pick one 'most likely to be future-proof' combination, either...
I'm going to, anyway: The Web. Straight up HTTP, with HTML documentation. Fall back to plain-text if you're extra-paranoid, but if you don't do any styling, straight HTML is very future-proof and backwards-compatible. If you do anything on top of that (Dav, etc), document it as completely as you can in that documentation.
I don't really see how wireless is any more likely to be accessible than a plug -- I would argue less so, as wireless standards can change, but no one can legally prevent you from having functioning Ethernet (or Token Ring, etc). If there's a concern of making this thing outlast Ethernet and (say) ipv4, include anything you're paranoid about losing, and put a durable physical interface on the thing so your great-grandkids can read the minimum documentation they need to rig an interface, then read the rest of it comfortably in whatever a web browser looks like by 2095, as they try to code an interface to it.
File types die over time and it's basically impossible to find programs to open certain files nowadays, much less such programs that will run on a modern OS. I think the answer to this has to be virtualization.
Or simply include all the programs needed in the original hardware, along with full specs of said hardware, so that virtualization can be built as-needed.
I'm not entirely sure which one is easier. I suspect that an active system is most reliable, as long as you have the money to pay people to look after it. I'd imagine that if you can't guarantee that constant flow of cash, the sanest thing to do is build the most durable physical system possible -- and then build two more -- and lock them away in a vault somewhere, so that a few thousand years from now, archaeologists can reverse-engineer whatever you had. I think that'd be a lot better than hoping there isn't a political upheaval in a few hundred years that cuts off funding, and making the job even harder for those inevitable archaeologists -- now they not only have to understand the original machine, they also have to understand several layers of virtualization.
At the same time, I really, really wouldn't want to try to maintain anything in which I wasn't allowed to upgrade.
One of the endpoints is my proxy. My browser wouldn't be talking https -- the proxy would be in the other room. In the event that I'm not home, I can VPN in, or use https to the proxy -- at a different URL.
It is only "not difficult" to write an https client if you leverage pre existing software such as openssl.
Which I'd naturally be doing. Probably without realizing it -- I'd just grab a decent http client library in the language of my choice.
The downside in both cases is that client loses all information about the proxy's counterparty, even if the proxy is fully trusted
Unless the proxy itself knows about its counterparty, if that word means what I think it means. And yes, the proxy would be fully trusted.
Spoofing that chain is computationally infeasible
Who said anything about spoofing the chain? This isn't meant to be transparent to the client, only the server.
Let me try to make this clear with my own ASCII chart:
Yes, totally insecure unless you trust that proxy, and you trust it to verify www.paypal.com, or present some sort of an interface for you to verify it yourself -- a web/GUI interface, not some trick with https.
Utterly pointless, of course, as every browser I've used lately has some sort of user-agent spoofing, but it may be needed if PayPal uses more than the user-agent. But still pointless, as PayPal has apparently claimed they won't block browsers.
No, you didn't. You're using this to make some sort of point.
Or, if you did, you did not use a method of flipping which is fair -- you're using something which deliberately supports this argument.
You see, a quick calculation shows that the chances of that happening is approximately 0.000000000000088817841970012523233890533447265625%
Which should also show you something about determinism. At a certain point, we can reasonably discard a possibility -- if you flip a coin a half million times, it won't come up heads every time. Similarly, at a certain point, we can reasonably assume a possibility -- if you flip a coin ten times, then repeat that experiment a million times, you're probably going to get all heads at least once. (In fact, you'll probably get all heads over 900 times, out of a million attempts.)
I may have the math wrong here, it has been awhile. But predictions like this are easy to come by. In fact, perfect randomness has some patterns in it -- enough that Apple had to make their Shuffle mode less random, lest people start to assume their iPod has a mind of its own.
I went back and checked and I am not generating any inline JS or ExtJS within PHP or any markup templates...
I'm still not sure what this would change, unless you can argue that a code generation tool must be included under the same license.
At which point, where does it stop? Must all text editors be distributed under an open source license?
IANAL, but again, I find it difficult to imagine how code generators could be covered. I should probably go back and read the GPL, though, as I'm sure it says something about it. I know it specifically clarifies the case where a code generator, compiler, etc is GPL'd, but the result of it need not be GPL'd -- thus, you can use emacs and gcc to develop proprietary projects, even though both would probably be GPLv3 by now.
our university tied MACS to IPs, and usernames to MACS.
Makes sense...
Spoofing a mac on a different network would mean that the tuple didn't match
This I don't get. Are you not allowed to move between networks?
See, I could physically plug my laptop into anywhere on campus, and expect it to work. Or I could turn on the wireless -- different mac address, but bound to the same username and IP -- and expect it to work.
But I didn't have to login every time. Therefore, someone else could easily have spoofed my MAC on the same wireless network. I don't know, but I suspect, that they could also have spoofed it on a different physical network -- if I'm lucky, the school might ping me, but that's not exactly infallible, especially when most firewalls block ping.
\
Spoofing a MAC prior to registering doesn't help
Right, but if you don't register, you don't get an IP. All an attacker would really have to do is sniff wireless traffic, find a valid IP, look at the MAC behind it, and spoof that. On a physical network, it would be a bit harder, as there might be a router in the way -- but you could probably find IPs on your local network to spoof, then go to a different local network and spoof them (simulating that user moving across networks). That basically prevents there from being one switch to figure it out.
I haven't tested this, but I have no reason to believe it wouldn't work.
MAC spoofing is rare, but also quite easy to block on the switch, long before any damning traffic occurred.
Wait, what? How does this happen?
I mean, yes, it'd be somewhat more difficult if we're not on the same network, but there's always other networks, and wifi, on any sufficiently large campus. Besides, my understanding is that a switch can't know which nic actually "owns" that mac address, thus whoever had it first "wins" and gets the IP also.
And then, there's always the possibility of simply registering a spoofed address on purpose, knowing I can then un-spoof it if I'm caught, and claim that it wasn't my laptop.
This is why some universities don't allow wireless access points to be connected to the network
And some universities provide their own wireless access points. Some of them even allocate real, Internet-visible ipv4 addresses to every laptop.
The compression ratios aren't easily predicted, so the effective free space is unknown, and depends on the kind of data.
Still, you should be able to get a reliable measure of the minimum free space. Just detect if compression ever made a chunk bigger than it was to begin with, and if so, store without compression.
The one disadvantage is that you can no longer be absolutely sure, once you've allocated some space, that it's available -- but you probably want to be using sparsefiles and such instead of pre-allocating anyway.
any top-level application code must be GPL'd due to the distributed nature of web applications. The inherent act of pulling the client-side code down to the browser categorizes this as distribution...
Of the client-side code, yes.
What I don't get is how he thinks that also applies to the server-side code. Tightly coupled or not, the GPL traditionally refers to things which are actually linked against each other -- for example, it is entirely possible to have a non-GPL'd program depend on, say, a GPL'd bash. And then there are things like Second Life, where the client is GPL'd, but the server isn't available under any license -- sure, they are tightly coupled, but there's still a network in the way.
Whether or not you think the GPL should apply to the other end of the connection, I'm pretty sure it legally doesn't, and I can't see how you could enforce that, anyhow. Does that mean that if I write a GPL'd client for Google Search (for things like Google Fight, say), could I then demand Google to give me their PageRank algorithm? You could say it only applies to apps in which client and server are developed together, but how the hell do you define that clearly enough to work? And again, how does it protect you against a third party using your API?
Now I'm very much concerned whether I should be using this package at all - not based on the quality of the software - but based on the leadership instability and capricious nature of this licensing switch.
Is the leadership unstable?
I can see both sides on the switch, though. I can see why it seems kind of sneaky and underhanded that they'd change the license out from under you, with no notice. But at the same time, I really don't see this changing many apps -- I suspect most of them will have a backend that ext can't touch. And, as you say, you were planning to pay the commercial license anyway -- so the only thing this changes is your perception of the guy.
However disk encryption on the whole can and will slow computers down, not significantly on modern computers but it does.
Really not significantly.
I haven't done any benchmarks of the speed of the drive itself, though I suspect it adds some latency. But the actual CPU usage is insignificant, compared to just about anything else you might do on the machine.
Seriously, ntfs-3g is going to be a MUCH bigger slowdown -- yet I've run ntfs-3g on top of dm-crypt, and it was still usable. Just did a quick "find/", and watched top, and while find itself occasionally climbed to 10% CPU (and on Linux, that means 10% of one core), the actual kernel crypt process never rose above 1%. It's now installing software updates, and the kernel crypto process just rose to 15%.
Another statistic: After four days of using this computer since the last full reboot (hibernating every now and then), one crypt process has accumulated a little over an hour of CPU time. The other has a little over a second.
Keep in mind, most software doesn't know how to take advantage of more than one core, so most people do actually have most of a core just sitting idle. That's why dual-core feels faster. If, under heavy load, the crypt process might -- maybe -- take 20% of that core, you're still not really going to feel it. And most truly CPU-intensive tasks, like games, video encoding, raytracing, etc, are not incredibly disk-intensive.
All in all, I think that outside of embedded disks, the CPU time we spend on our storage isn't really relevant. At this point, doing some simple lzo compression may actually improve performance, as you're still going to be faster than the disk is, and reading less raw data from the disk takes less time.
No, the real reason we're seeing this in hardware is because Windows will support it, and easily. I imagine there's a fair chance there's some BIOSes out there that do it in software, too.
Ok, if I'd hit "a" to those cookies, it would've been a lot better. And there are a fscking LOT of cookies.
Now, I haven't actually tried to do anything with it so far, but I suspect that it would, in fact, work just fine. It's curious that it doesn't like the SSL -- I suspect that's a problem with my version of Lynx, as Firefox and Konqueror don't give me any SSL warnings. But other than that, Paypal isn't doing anything to block Lynx, and it looks reasonably navigateable.
It's not difficult to write an https client. It's marginally difficult to intercept all link URLs and replace them -- only really difficult because JavaScript may be involved, and it may be possible to simply filter JavaScript.
Regardless, I'll probably deal with it in a much simpler way: User-Agent spoofing till I can transfer my funds to people who don't discriminate by OS and browser.
Why not six days? Why not what appears to be a Big Bang taking six days?
Occam's Razor.
Which is easier to believe -- a book, assembled by humans; or the evidence before our own eyes, which we've been looking at for generations?
Or, take this back to Galileo's problem. Which is easier to believe -- that God has seen fit to spin and tinker with the Celestial Spheres just so to make it appear as though things orbit the sun, when they really orbit the Earth? Or is it easier to believe that things orbit the Sun, and the Bible need not be interpreted so literally?
Sure god could have taken millions of years, I just don't think it happened that way
Again: Why not?
For not agreeing that some of evolution is random chance, it sure does sound like you start your comment off that way.
Alright, do this experiment for me: Go and buy a lottery ticket. You won't win.
Yes, it's random, but you won't win. You are less likely to win the jackpot than you are to be struck by lightning.
Or try this one: Flip a coin ten times. If you know anything about probability math, you'd expect 5 heads and 5 tails. I'll bet it's not exactly that, though -- maybe more like six and four, maybe even seven and three. Probably not ten all one way or the other.
Now flip a coin a hundred times. It's probably going to be much closer this time -- probably not more than ten off, fifty-something one way, fifty-something the other.
Flip the same coin a thousand times. The more repetitions, the closer you get to the expected outcome, knowing that on any given flip, you have a random chance of getting heads or tails, and they are equally probable.
It may bother you that there is randomness at the core of this, but a lot of certainty can be built from randomness. The fact that every atom in your body didn't simultaneously jump a foot left is a result of probability -- and it's interesting that people find probability so hard to believe when we're talking about evolution, but no one questions it when we're talking about quantum physics. Is it really that probability is hard to believe, or that you desperately want to believe your scripture?
I think it applies the opposite way -- the fallacy of the broken window is that the shopkeeper is forced to spend money he otherwise doesn't have to. He spends money on the glazier, instead of the baker -- the glazier could then spend money on the baker.
In this story, the proprietary vendors are the glaziers. The glazier may indeed lose business, but it is no cost to the economy as a whole, and it is a benefit to the shopkeeper, who can now spend money on things other than software.
To understand biology, you absolutely must understand the fact of evolution, at least on a micro scale. You don't have to believe it's the origin of species, but there are certain parts of it that you must at least accept, or you won't understand biology.
if someone put such a disclaimer in about Einstein's relativity I'd applaud them, or Newton's gravity
But, you see, no one does. And I imagine most people wouldn't put such a disclaimer on these things -- only Evolution gets the "just a theory" stickers.
Your example of Newtonian gravity isn't entirely valid -- Newtonian gravity was disproved by Einstein's Relativity. Do you see similar stickers on Relativity?
That, and Newtonian gravity is still used. It has not been wholly discarded -- Relativity is a refinement of Newtonian physics. If you look at the equations, Newtonian gravity is still there, just with a few additional terms multiplied in that usually end up being close enough to 1 that we can ignore them.
Are scientists supposed to be neutral unbiased parties?
No.
Science itself is supposed to be neutral and unbiased. But a scientist absolutely is allowed to have an opinion, so long as they don't pretend that opinion is science.
For the most part modern scientists are good about being neutral, except when you bring up the ol' Evolution.
Because evolution is generally widely accepted in the scientific community, and if you actually read up on it, it makes sense, and it has been tested. It's pretty much as solid as gravity.
So when someone questions it, there are generally three possibilities:
They don't quite understand it yet.
They don't want to understand it; they'd rather believe the world is six thousand years old (which means they're also going against geology).
They have genuinely found something wrong with evolutionary theory. Which would suggest that we should revise the theory, not throw it away entirely.
Which seems more likely?
Yes, it could be #3 -- but that is more like Einstein refining Newton's theory. No one's suggesting that gravity be thrown out, and we go back to Aristotle's (I think) theories of things falling because they are "earthly", and stars not falling because they are "heavenly".
The reason you get this response is that almost every argument against Darwin is exactly like the arguments against Galileo. We all know how that turned out.
Slashdot Mirror
How much money do you really need?
If I was doing illegal botnets, I'd make a cool billion dollars or so, then retire to a tropical island.
By the time a user is participating in a botnet, they are a lost cause. If you want to help them, fine, but do it before they get infected.
And anyone who doesn't do backups WILL lose data, it's only a question of when.
I realize that I'm one of probably fifteen or twenty threads here, but it looks like people are still coming up with all kinds of inventive ways around the fact that it is an untrusted terminal. Untrusted means anything you do on that terminal is subject to being messed with.
Most of the smarter methods revolve around authentication -- one-time-pads, etc. That'll protect you from a keylogger, but what about a pwned web browser? And yes, you run yours off the USB device -- suppose the whole OS is pwned, and injects screen-scraping-logging into your USB web browser. Worse, suppose it mods the EXE to contain itself, so that even if you never get hit, you're a carrier -- the next time you open it at another internet cafe, you'll infect them.
Then there are the stupid methods -- copy/paste, drag characters around, character map, etc. That's an OK skill to have when your keyboard breaks -- just recently, Ubuntu decided my Apple USB keyboard is a Macbook keyboard, so numlock would kill half my keyboard until I restarted X. But this kind of only-use-the-mouse mentality is pointless on a public terminal -- fine, you've defeated most hardware keyloggers, and you've defeated the dumber software ones. The smarter one saw you click a button, or hit enter, and grabbed the value of the form element at that point.
The closest I can think of to something that might work is to boot from a livecd, AND use the mouse for everything. In which case, you're still vulnerable to screen capture (grab an image on every mouse click, say), and to things like the Blue Pill proof-of-concept -- what makes you think it's actually booting your livecd on bare metal, and not in some virtual machine?
For all the effort you would spend thinking up schemes like these, and slowly realizing how they can be defeated, it's probably easier just to buy an EEE PC. Control the endpoint, and problem solved, barring insanely difficult and unreliable schemes like tempest. (There was even one which could figure out your password by listening to your keystrokes.)
I'm not sure I really see the point -- if you're carrying around a PDA anyway, get a beefier one, get wireless on it, and use that. Control your endpoints.
That said, you could go to the other extreme and commoditize it -- PayPal will sell you a hardware key for $5 or so, which generates pseudorandom number every 30 seconds or so. This same key can be used with VeriSign's OpenID service. It'd probably cost a bit more to put it entirely under your control -- so that you're the one who initializes the key, and you're entering it into your own server, not PayPal's or VeriSign's -- but the idea is the same.
The obvious difference is, with your own real endpoint, you can actually work with private data. What the key buys you on a public terminal is the knowledge that if they didn't do anything to your account by the time you log out, you're safe. But you're still vulnerable to things like session hijacking and simple logging -- at the very least, they could capture the screen at intervals.
But seriously, why not https, a VPN, something like that? I don't imagine EVDO is going to be as fast or as reliable as wifi, wherever the wifi is available.
Yes, some applications can easily be proprietary. It's even possible to argue that some applications can only reasonably be made proprietary -- cases where security-through-obscurity is a necessity of the problem space, and there's not a lot you can do about it. (MMOs come to mind.)
The Flash Player is not something which should be proprietary. It is the exact polar opposite of something which should be proprietary.
What I find ironic is that what many people see as indispensable are the authoring tools, yet you are free to actually go and read the Flash spec for those. The only thing you are not allowed to do is both read the spec and create a player from it.
...Where?
All I see are a bunch of people trying to grab some funding and then disappear.
I'm going to, anyway: The Web. Straight up HTTP, with HTML documentation. Fall back to plain-text if you're extra-paranoid, but if you don't do any styling, straight HTML is very future-proof and backwards-compatible. If you do anything on top of that (Dav, etc), document it as completely as you can in that documentation.
I don't really see how wireless is any more likely to be accessible than a plug -- I would argue less so, as wireless standards can change, but no one can legally prevent you from having functioning Ethernet (or Token Ring, etc). If there's a concern of making this thing outlast Ethernet and (say) ipv4, include anything you're paranoid about losing, and put a durable physical interface on the thing so your great-grandkids can read the minimum documentation they need to rig an interface, then read the rest of it comfortably in whatever a web browser looks like by 2095, as they try to code an interface to it.
Or simply include all the programs needed in the original hardware, along with full specs of said hardware, so that virtualization can be built as-needed.
I'm not entirely sure which one is easier. I suspect that an active system is most reliable, as long as you have the money to pay people to look after it. I'd imagine that if you can't guarantee that constant flow of cash, the sanest thing to do is build the most durable physical system possible -- and then build two more -- and lock them away in a vault somewhere, so that a few thousand years from now, archaeologists can reverse-engineer whatever you had. I think that'd be a lot better than hoping there isn't a political upheaval in a few hundred years that cuts off funding, and making the job even harder for those inevitable archaeologists -- now they not only have to understand the original machine, they also have to understand several layers of virtualization.
At the same time, I really, really wouldn't want to try to maintain anything in which I wasn't allowed to upgrade.
One of the endpoints is my proxy. My browser wouldn't be talking https -- the proxy would be in the other room. In the event that I'm not home, I can VPN in, or use https to the proxy -- at a different URL.
Which I'd naturally be doing. Probably without realizing it -- I'd just grab a decent http client library in the language of my choice.
Unless the proxy itself knows about its counterparty, if that word means what I think it means. And yes, the proxy would be fully trusted.
Who said anything about spoofing the chain? This isn't meant to be transparent to the client, only the server.
Let me try to make this clear with my own ASCII chart:
Yes, totally insecure unless you trust that proxy, and you trust it to verify www.paypal.com, or present some sort of an interface for you to verify it yourself -- a web/GUI interface, not some trick with https.
Utterly pointless, of course, as every browser I've used lately has some sort of user-agent spoofing, but it may be needed if PayPal uses more than the user-agent. But still pointless, as PayPal has apparently claimed they won't block browsers.
No, you didn't. You're using this to make some sort of point.
Or, if you did, you did not use a method of flipping which is fair -- you're using something which deliberately supports this argument.
You see, a quick calculation shows that the chances of that happening is approximately 0.000000000000088817841970012523233890533447265625%
Which should also show you something about determinism. At a certain point, we can reasonably discard a possibility -- if you flip a coin a half million times, it won't come up heads every time. Similarly, at a certain point, we can reasonably assume a possibility -- if you flip a coin ten times, then repeat that experiment a million times, you're probably going to get all heads at least once. (In fact, you'll probably get all heads over 900 times, out of a million attempts.)
I may have the math wrong here, it has been awhile. But predictions like this are easy to come by. In fact, perfect randomness has some patterns in it -- enough that Apple had to make their Shuffle mode less random, lest people start to assume their iPod has a mind of its own.
That's interesting, given that the Unix Epoch expires late January of 2038.
I'm still not sure what this would change, unless you can argue that a code generation tool must be included under the same license.
At which point, where does it stop? Must all text editors be distributed under an open source license?
IANAL, but again, I find it difficult to imagine how code generators could be covered. I should probably go back and read the GPL, though, as I'm sure it says something about it. I know it specifically clarifies the case where a code generator, compiler, etc is GPL'd, but the result of it need not be GPL'd -- thus, you can use emacs and gcc to develop proprietary projects, even though both would probably be GPLv3 by now.
Makes sense...
This I don't get. Are you not allowed to move between networks?
See, I could physically plug my laptop into anywhere on campus, and expect it to work. Or I could turn on the wireless -- different mac address, but bound to the same username and IP -- and expect it to work.
But I didn't have to login every time. Therefore, someone else could easily have spoofed my MAC on the same wireless network. I don't know, but I suspect, that they could also have spoofed it on a different physical network -- if I'm lucky, the school might ping me, but that's not exactly infallible, especially when most firewalls block ping.
\Right, but if you don't register, you don't get an IP. All an attacker would really have to do is sniff wireless traffic, find a valid IP, look at the MAC behind it, and spoof that. On a physical network, it would be a bit harder, as there might be a router in the way -- but you could probably find IPs on your local network to spoof, then go to a different local network and spoof them (simulating that user moving across networks). That basically prevents there from being one switch to figure it out.
I haven't tested this, but I have no reason to believe it wouldn't work.
Wait, what? How does this happen?
I mean, yes, it'd be somewhat more difficult if we're not on the same network, but there's always other networks, and wifi, on any sufficiently large campus. Besides, my understanding is that a switch can't know which nic actually "owns" that mac address, thus whoever had it first "wins" and gets the IP also.
And then, there's always the possibility of simply registering a spoofed address on purpose, knowing I can then un-spoof it if I'm caught, and claim that it wasn't my laptop.
And some universities provide their own wireless access points. Some of them even allocate real, Internet-visible ipv4 addresses to every laptop.
Meaning more latency, and more CPU usage -- but not, as far as I can tell, less throughput.
So, if it's a single-threaded h.264 movie, and you're using a significantly large cache in your player, you should be fine.
Still, you should be able to get a reliable measure of the minimum free space. Just detect if compression ever made a chunk bigger than it was to begin with, and if so, store without compression.
The one disadvantage is that you can no longer be absolutely sure, once you've allocated some space, that it's available -- but you probably want to be using sparsefiles and such instead of pre-allocating anyway.
Of the client-side code, yes.
What I don't get is how he thinks that also applies to the server-side code. Tightly coupled or not, the GPL traditionally refers to things which are actually linked against each other -- for example, it is entirely possible to have a non-GPL'd program depend on, say, a GPL'd bash. And then there are things like Second Life, where the client is GPL'd, but the server isn't available under any license -- sure, they are tightly coupled, but there's still a network in the way.
Whether or not you think the GPL should apply to the other end of the connection, I'm pretty sure it legally doesn't, and I can't see how you could enforce that, anyhow. Does that mean that if I write a GPL'd client for Google Search (for things like Google Fight, say), could I then demand Google to give me their PageRank algorithm? You could say it only applies to apps in which client and server are developed together, but how the hell do you define that clearly enough to work? And again, how does it protect you against a third party using your API?
Is the leadership unstable?
I can see both sides on the switch, though. I can see why it seems kind of sneaky and underhanded that they'd change the license out from under you, with no notice. But at the same time, I really don't see this changing many apps -- I suspect most of them will have a backend that ext can't touch. And, as you say, you were planning to pay the commercial license anyway -- so the only thing this changes is your perception of the guy.
Really not significantly.
I haven't done any benchmarks of the speed of the drive itself, though I suspect it adds some latency. But the actual CPU usage is insignificant, compared to just about anything else you might do on the machine.
Seriously, ntfs-3g is going to be a MUCH bigger slowdown -- yet I've run ntfs-3g on top of dm-crypt, and it was still usable. Just did a quick "find /", and watched top, and while find itself occasionally climbed to 10% CPU (and on Linux, that means 10% of one core), the actual kernel crypt process never rose above 1%. It's now installing software updates, and the kernel crypto process just rose to 15%.
Another statistic: After four days of using this computer since the last full reboot (hibernating every now and then), one crypt process has accumulated a little over an hour of CPU time. The other has a little over a second.
Keep in mind, most software doesn't know how to take advantage of more than one core, so most people do actually have most of a core just sitting idle. That's why dual-core feels faster. If, under heavy load, the crypt process might -- maybe -- take 20% of that core, you're still not really going to feel it. And most truly CPU-intensive tasks, like games, video encoding, raytracing, etc, are not incredibly disk-intensive.
All in all, I think that outside of embedded disks, the CPU time we spend on our storage isn't really relevant. At this point, doing some simple lzo compression may actually improve performance, as you're still going to be faster than the disk is, and reading less raw data from the disk takes less time.
No, the real reason we're seeing this in hardware is because Windows will support it, and easily. I imagine there's a fair chance there's some BIOSes out there that do it in software, too.
Nah, Lynx was always like that...
Oh my god.
That's where Microsoft got UAC from! Combine lynx with sudo, and... *shudders*
While I suspect that, yes, Boll would probably love it to have a million people hate him...
It's still worth a shot. Mostly because ignoring him won't make him go away, but a million signatures would at least make him a liar if he didn't.
lynx https://www.paypal.com/ ...
SSL error:no issuer was found-Continue? (y) y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: cookie_check=yes Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: navcmd=_home-general Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: navlns=0.0 Allow? (Y/N/Always/neVer)y
# FINALLY there's a homepage. "Member Log In" is on the second page.
SSL error:no issuer was found-Continue? (y) y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
Refresh: 1 seconds
https://.../
SSL error:no issuer was found-Continue? (y) y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
Ok, if I'd hit "a" to those cookies, it would've been a lot better. And there are a fscking LOT of cookies.
Now, I haven't actually tried to do anything with it so far, but I suspect that it would, in fact, work just fine. It's curious that it doesn't like the SSL -- I suspect that's a problem with my version of Lynx, as Firefox and Konqueror don't give me any SSL warnings. But other than that, Paypal isn't doing anything to block Lynx, and it looks reasonably navigateable.
What makes you think I'll be connecting to my proxy as https://www.paypal.com?
It's not difficult to write an https client. It's marginally difficult to intercept all link URLs and replace them -- only really difficult because JavaScript may be involved, and it may be possible to simply filter JavaScript.
Regardless, I'll probably deal with it in a much simpler way: User-Agent spoofing till I can transfer my funds to people who don't discriminate by OS and browser.
Occam's Razor.
Which is easier to believe -- a book, assembled by humans; or the evidence before our own eyes, which we've been looking at for generations?
Or, take this back to Galileo's problem. Which is easier to believe -- that God has seen fit to spin and tinker with the Celestial Spheres just so to make it appear as though things orbit the sun, when they really orbit the Earth? Or is it easier to believe that things orbit the Sun, and the Bible need not be interpreted so literally?
Again: Why not?
Alright, do this experiment for me: Go and buy a lottery ticket. You won't win.
Yes, it's random, but you won't win. You are less likely to win the jackpot than you are to be struck by lightning.
Or try this one: Flip a coin ten times. If you know anything about probability math, you'd expect 5 heads and 5 tails. I'll bet it's not exactly that, though -- maybe more like six and four, maybe even seven and three. Probably not ten all one way or the other.
Now flip a coin a hundred times. It's probably going to be much closer this time -- probably not more than ten off, fifty-something one way, fifty-something the other.
Flip the same coin a thousand times. The more repetitions, the closer you get to the expected outcome, knowing that on any given flip, you have a random chance of getting heads or tails, and they are equally probable.
We call this the Law of Large Numbers.
It may bother you that there is randomness at the core of this, but a lot of certainty can be built from randomness. The fact that every atom in your body didn't simultaneously jump a foot left is a result of probability -- and it's interesting that people find probability so hard to believe when we're talking about evolution, but no one questions it when we're talking about quantum physics. Is it really that probability is hard to believe, or that you desperately want to believe your scripture?
I think it applies the opposite way -- the fallacy of the broken window is that the shopkeeper is forced to spend money he otherwise doesn't have to. He spends money on the glazier, instead of the baker -- the glazier could then spend money on the baker.
In this story, the proprietary vendors are the glaziers. The glazier may indeed lose business, but it is no cost to the economy as a whole, and it is a benefit to the shopkeeper, who can now spend money on things other than software.
That's too vague a question, really.
To understand biology, you absolutely must understand the fact of evolution, at least on a micro scale. You don't have to believe it's the origin of species, but there are certain parts of it that you must at least accept, or you won't understand biology.
But, you see, no one does. And I imagine most people wouldn't put such a disclaimer on these things -- only Evolution gets the "just a theory" stickers.
Your example of Newtonian gravity isn't entirely valid -- Newtonian gravity was disproved by Einstein's Relativity. Do you see similar stickers on Relativity?
That, and Newtonian gravity is still used. It has not been wholly discarded -- Relativity is a refinement of Newtonian physics. If you look at the equations, Newtonian gravity is still there, just with a few additional terms multiplied in that usually end up being close enough to 1 that we can ignore them.
No.
Science itself is supposed to be neutral and unbiased. But a scientist absolutely is allowed to have an opinion, so long as they don't pretend that opinion is science.
Because evolution is generally widely accepted in the scientific community, and if you actually read up on it, it makes sense, and it has been tested. It's pretty much as solid as gravity.
So when someone questions it, there are generally three possibilities:
Which seems more likely?
Yes, it could be #3 -- but that is more like Einstein refining Newton's theory. No one's suggesting that gravity be thrown out, and we go back to Aristotle's (I think) theories of things falling because they are "earthly", and stars not falling because they are "heavenly".
The reason you get this response is that almost every argument against Darwin is exactly like the arguments against Galileo. We all know how that turned out.