At present you run into an issue where you could mount an ext2 or ext3 drive as a certain user, write files to it, and be unable to do anything with those files if you have a different UID on a different system.
A kernel patch has been proposed to allow you to remap ext2/3 UIDs when mounting a disk so that a standard UID can be mapped to whoever mounts the drive. This way, you'll be able to use ext2 or ext3 as your flash filesystem, preserve capitalization (another vfat weak point) and permissions (modulo the remapping) and still have decent interchange between different Linux boxes where you have different UIDs.
And here we have emperical evidence that Microsoft's bundling of IE does hurt the competition. OpenOffice can get a foothold on Windows becuase its competitor costs money, but Firefox can't because its competitor is free, and is built into every copy of Windows.
Open source can deliver just fine. We've got CalDav, IMAP, OpenOffice, etc... for doing your basic and advanced office functions. Your mistake is confusing Google Apps with open source software.
Thanks to gun control laws, there aren't any AK-47s around to be seen, so why would you expect a layman to know what an AK-47 looks like and how to tell it apart from a fake Halo sniper rifle?
I administer a machine that can take up to 12GB of RAM (we're trying now to decide whether to put more than 4GB in it), but doesn't support the lm flag (i.e. it only has a 32-bit processor). The machine is over 4 years old.
I guess I misunderstood. He must have been talking about the project standpoint where alice updates foo.c and bob updates bar.c. I don't think they have to see each other's changes to commit. But if they touch the same file, even though their changes don't textually conflict, then they do have to see each other's changes.
Additionally, he mentions (at the end of the article) that distributed systems have issues with old projects that have long histories as an area for further research. He doesn't discuss bzr, which has a SVN-like mode for working with repositories when an overly-large history size is a real issue. He also doesn't discuss git clone --depth which may help with such issues. The git documentation is overly conservative when describing what you can do with a depth-limited repository -- there are plenty of conditions under which you can push to remote branches and merge other peoples' work when your history goes back far enough -- the git developers just don't want to say what those are.
Maybe there's room for more research, but there are some solutions out there already that are worth discussing.
They discuss darcs, but it's too esoteric for them to understand, so they don't discuss it too much. And they don't really go into differences between git and hg (if there are any).
Because Subversion offers working out of a shared branch as the path of least resistance, developers tend to do so blindly without understanding the risk they face. In fact, the risks are even subtler: suppose that Alice's changes do not textually conflict with Bob's; she will not be forced to check out Bob's changes before she commits, so she can commit her changes to the server unimpeded, resulting in a new tree state that no human has ever seen or tested.
This statement is incorrect. Subversion requres you to update your working copy before committing whenever you have modified a file that has changed in the repository.
I recently did configuration work on linux boxes that had 4 GB in RAM in them, but couldn't see more than 1GB of it because the previous administrator had neglected to enable CONFIG_HIGHMEM4G in the kernel configuration.
And to see more than 4GB of RAM on a Debian box, you need to use a special -bigmem kernel that has CONFIG_HIGHMEM64G enabled, because handling physical memory addresses more than 32-bits wide slows everything down, so Debian opted not to enable CONFIG_HIGHMEM64G by default.
So your Linux boxes *could* have these issues, and you do need to worry about it.
(Get a 64-bit kernel on a 64-bit processor and you're fine, though.)
The interesting thing here was that they do install 2 kernels on the desktop, one with PAE and one without. They cripple the PAE-enabled kernel even if you use it on the desktop for stupid reasons.
They *could* have invent real architectural limitation by not installing the PAE kernel at all on desktops (just don't include it on the CD, and force everyone to use a non-PAE enabled kernel), but they don't. Rather, they install it, and then restrict it with a registry key.
They should be selling the 64-bit version. They should be preinstalling the 64-bit version. People *shouldn't* be using the 32-bit version, becuase there's still a very real architectural limitation in the 32-bit version: a given process can only see 3 GB of memory, no matter how you set up your licensing.
That sounds like a better system than what Chicago's got. It also solves certain problems with motorcycles that don't have a secure place to put a receipt where you can be sure it won't be stolen.
The ParkMagic in-car meter is a scam on the part of the city to steal your paid-for parking time from you. (To be fair, the new smart meters a half a block away from you are probably a scam too). It used to be that if you had extra time on the meter, someone else could park there for the extra time and save themselves money. Considering that if someone else left with extra time you could park in their spot and take advantage of the free time, over the long run it would tend to average out that you were only paying for the actual time you spent parked in your spot.
Now with the new changes, nobody else can take advantage of leftover time on your meter when you leave, and you can't get any kind of refund. So all of the extra time that people pay for -- the city's getting their money for free.
That's probably a really hard hack to pull off. But I doubt most users would notice anything if they got an RSA SecurID password wrong once -- they'd assume it's a typo.
(By the way, I don't see any information saying RSA SecurID only lets you use the token once. Sure it changes every 60 seconds, so that's as good as "once", but if two people happened to be racing to type in the same code at the same time, I don't see anything saying it would deny access.)
What's so wrong about the hotel room tax anyway? It's enforceable, it doesn't put undue burden on companies outside its jurisdiction. They have to get their room rates from the hotels in NYC anyway and have to confirm reservations with the hotels in NYC anyway, so the burden is really on the hotels to give the appropriate pricing information and make sure the tax gets to the right place. And the hotels know where their reservations are coming from.
In truth, all you need to do is read the Art of War, and you'll know that implementing proper Windows permissions couldn't possibly the the answer to security. You'll also realize that collaborative filtering couldn't possibly the the answer to security either.
The only answer is to be one step ahead of the attackers, and to think up what they're going to throw at you next.
(That's not to say that proper Windows permissions don't help, and that collaborative filtering doesn't help, but security is war, and the white hats need to keep trying to win. Just because you have a certain security measure doesn't mean you're secure.)
I don't think that the following is such a good final exam question:
Trace the connections between Darwinian evolution, eugenics, abortion, infanticide, and euthanasia. Why are materialists so ready to embrace these as a package deal? What view of humanity and reality is required to resist them?
Because giving a suitable answer would be way way way too long for a final. But really, worded a little less provocatively, it's a great topic for a doctoral dissertation in philosophy.
Slashdot Mirror
At present you run into an issue where you could mount an ext2 or ext3 drive as a certain user, write files to it, and be unable to do anything with those files if you have a different UID on a different system.
A kernel patch has been proposed to allow you to remap ext2/3 UIDs when mounting a disk so that a standard UID can be mapped to whoever mounts the drive. This way, you'll be able to use ext2 or ext3 as your flash filesystem, preserve capitalization (another vfat weak point) and permissions (modulo the remapping) and still have decent interchange between different Linux boxes where you have different UIDs.
And here we have emperical evidence that Microsoft's bundling of IE does hurt the competition. OpenOffice can get a foothold on Windows becuase its competitor costs money, but Firefox can't because its competitor is free, and is built into every copy of Windows.
At UC Davis, the entire computer science department is in Linux, as well as a couple of other departments.
Open source can deliver just fine. We've got CalDav, IMAP, OpenOffice, etc... for doing your basic and advanced office functions. Your mistake is confusing Google Apps with open source software.
Thanks to gun control laws, there aren't any AK-47s around to be seen, so why would you expect a layman to know what an AK-47 looks like and how to tell it apart from a fake Halo sniper rifle?
Was letting two companies lose people's votes any better?
Are the science and money there to make it happen in a paradigm-shifting way? Or is it just a bunch tweaks on existing industries?
I administer a machine that can take up to 12GB of RAM (we're trying now to decide whether to put more than 4GB in it), but doesn't support the lm flag (i.e. it only has a 32-bit processor). The machine is over 4 years old.
To save some Googling, DEP=Data Execuation Prevention.
I guess I misunderstood. He must have been talking about the project standpoint where alice updates foo.c and bob updates bar.c. I don't think they have to see each other's changes to commit. But if they touch the same file, even though their changes don't textually conflict, then they do have to see each other's changes.
Additionally, he mentions (at the end of the article) that distributed systems have issues with old projects that have long histories as an area for further research. He doesn't discuss bzr, which has a SVN-like mode for working with repositories when an overly-large history size is a real issue. He also doesn't discuss git clone --depth which may help with such issues. The git documentation is overly conservative when describing what you can do with a depth-limited repository -- there are plenty of conditions under which you can push to remote branches and merge other peoples' work when your history goes back far enough -- the git developers just don't want to say what those are.
Maybe there's room for more research, but there are some solutions out there already that are worth discussing.
They discuss darcs, but it's too esoteric for them to understand, so they don't discuss it too much. And they don't really go into differences between git and hg (if there are any).
Because Subversion offers working out of a shared branch as the path of least resistance, developers tend to do so blindly without understanding the risk they face. In fact, the risks are even subtler: suppose that Alice's changes do not textually conflict with Bob's; she will not be forced to check out Bob's changes before she commits, so she can commit her changes to the server unimpeded, resulting in a new tree state that no human has ever seen or tested.
This statement is incorrect. Subversion requres you to update your working copy before committing whenever you have modified a file that has changed in the repository.
I recently did configuration work on linux boxes that had 4 GB in RAM in them, but couldn't see more than 1GB of it because the previous administrator had neglected to enable CONFIG_HIGHMEM4G in the kernel configuration.
And to see more than 4GB of RAM on a Debian box, you need to use a special -bigmem kernel that has CONFIG_HIGHMEM64G enabled, because handling physical memory addresses more than 32-bits wide slows everything down, so Debian opted not to enable CONFIG_HIGHMEM64G by default.
So your Linux boxes *could* have these issues, and you do need to worry about it.
(Get a 64-bit kernel on a 64-bit processor and you're fine, though.)
The interesting thing here was that they do install 2 kernels on the desktop, one with PAE and one without. They cripple the PAE-enabled kernel even if you use it on the desktop for stupid reasons.
They *could* have invent real architectural limitation by not installing the PAE kernel at all on desktops (just don't include it on the CD, and force everyone to use a non-PAE enabled kernel), but they don't. Rather, they install it, and then restrict it with a registry key.
They should be selling the 64-bit version. They should be preinstalling the 64-bit version. People *shouldn't* be using the 32-bit version, becuase there's still a very real architectural limitation in the 32-bit version: a given process can only see 3 GB of memory, no matter how you set up your licensing.
That sounds like a better system than what Chicago's got. It also solves certain problems with motorcycles that don't have a secure place to put a receipt where you can be sure it won't be stolen.
The ParkMagic in-car meter is a scam on the part of the city to steal your paid-for parking time from you. (To be fair, the new smart meters a half a block away from you are probably a scam too). It used to be that if you had extra time on the meter, someone else could park there for the extra time and save themselves money. Considering that if someone else left with extra time you could park in their spot and take advantage of the free time, over the long run it would tend to average out that you were only paying for the actual time you spent parked in your spot.
Now with the new changes, nobody else can take advantage of leftover time on your meter when you leave, and you can't get any kind of refund. So all of the extra time that people pay for -- the city's getting their money for free.
That's probably a really hard hack to pull off. But I doubt most users would notice anything if they got an RSA SecurID password wrong once -- they'd assume it's a typo.
(By the way, I don't see any information saying RSA SecurID only lets you use the token once. Sure it changes every 60 seconds, so that's as good as "once", but if two people happened to be racing to type in the same code at the same time, I don't see anything saying it would deny access.)
What's so wrong about the hotel room tax anyway? It's enforceable, it doesn't put undue burden on companies outside its jurisdiction. They have to get their room rates from the hotels in NYC anyway and have to confirm reservations with the hotels in NYC anyway, so the burden is really on the hotels to give the appropriate pricing information and make sure the tax gets to the right place. And the hotels know where their reservations are coming from.
In truth, all you need to do is read the Art of War, and you'll know that implementing proper Windows permissions couldn't possibly the the answer to security. You'll also realize that collaborative filtering couldn't possibly the the answer to security either.
The only answer is to be one step ahead of the attackers, and to think up what they're going to throw at you next.
(That's not to say that proper Windows permissions don't help, and that collaborative filtering doesn't help, but security is war, and the white hats need to keep trying to win. Just because you have a certain security measure doesn't mean you're secure.)
If it doesn't, they won't have much of a website left after today.
There's finally a use for this collaborative filtering technology.
I don't think that the following is such a good final exam question:
Trace the connections between Darwinian evolution, eugenics, abortion, infanticide, and euthanasia. Why are materialists so ready to embrace these as a package deal? What view of humanity and reality is required to resist them?
Because giving a suitable answer would be way way way too long for a final. But really, worded a little less provocatively, it's a great topic for a doctoral dissertation in philosophy.
I expected +5 Funny, for the clearly naive assumption that patents couldn't be licensed. Not +5 Insightful.