it's possible for a person who first gets cc'ed 15 replies into the conversation to start by reading the immediate message that he's supposed to comment on, and then read on down (if he cares) for as much context as he needs to figure out what that original issue was about (and then stop).
Only if you can read backwards. Otherwise you have to manually parse all the message headers and footers, searching for start and stop points, and then go back to read top-to-bottom like most humans. Wouldn't it be less work simply to scroll to the bottom once, read the last message, and then start scanning in-order from the beginning if you wanted more context? Or, you know, just start at the top and read down -- if people appropriately edited out old content you probably wouldn't feel the need to skip reading things that were sent to you.
First, asking who you are is a search. And you're generally welcome to refuse such searches. Apparently just not at airports.
Second, fishing licenses, library cards, passports and driver's licenses do not need to prove your identity. They need to prove your authorization to fish, check out books, enter the country and operate a vehicle respectively. They may contain information about your identity as a matter of convention or convenience, but that is not their purpose.
When you're fishing the ranger only needs to check that the person with a line in the water is the person to whom the fishing license was issued. And when they are issuing the license they only need to check that you meet the requirement -- in most cases the only requirement that you're a real person, though you may get a discount for living in a certain jurisdiction, or being a certain age. It seems entirely plausible that the DNR could print a card that said "Licensed to fish until 2008-12-31. Serial number: A12-34-B56', and contained my picture, or some other piece of authenticating information (ideally something totally anonymous, like my public key). Then the ranger could validate that I am the licensee, and could even check the serial number against the database to be sure the authorization hadn't been withdrawn, or the card modified. And at no point in this process would anyone need to know my name, or any other identifying information.
So, if the TSA wanted to issue me a card that said "Not a terrorist, OK to fly" and had my picture on it, I'd be happy to show them that. But they don't need to know who I am, and they don't need to be able to tie me to any other databases or identifying information. The fact that I want to leave my immediate geographic area does not make me suspicious. Millions upon millions of people who aren't committing crimes (let alone flight-related crimes) travel every year; that by it's nature makes travel a "typical" behavior, which by definition is not suspicious.
Frankly I don't understand why they can demand credentials even *with* cause. I mean, it's expedient, but I don't see how the justice system falls apart if you can't immediately ascertain someone's name and birthdate. In the modern era adults regularly carry government-issued credentials with them. But that wasn't always the case, and things seemed to work out okay.
Moreover I think it's absurd that your driver's license contains anything other than a number that can be used to tie your original test results to some sort of authentication system (we currently use a picture, there are better and more anonymous alternatives) and to tie driving-related court records to a specific licensee. In a traffic stop the cop needs to know that the person driving has been authorized to do so, and that the authorization has not been withdrawn. He does not need to know my name, birthdate, or any other identifying information.
And after the traffic stop, even if I am citied, the government does not have a legitimate need to track any additional information in relation to my traffic violation. You should not be able to determine where I live, when I was born, what personal or real property I own, or lookup other non-traffic convictions simply by knowing my driver's license number. We've allowed this to happen because it's convenient for law enforcement, but that's a pretty weak defense against the potential (and demonstrable) abuse.
It's not just drivers licensing either. if you're arrested for any reason, even if you are never charged and are released within minutes of being booked, the police will keep your fingerprints, DNA, and anything else they can get their hands on. They'll tie that information to your real and personal property registrations, your address, name, birthdate, drivers license, social security, and phone numbers. In some jurisdictions you can request that these records be destroyed, but it doesn't happen automatically. And in most jurisdictions you have no way to remove all this tracking information from law enforcement databases. There is simply no need for the government to keep those records; they are collected and stored simply as a convenience to law enforcement, to make prosecution more efficient. Not more just mind you -- I could tolerate some of the tracking if I believed it improved justice -- just more efficient.
First, the government is under an obligation to prove I am not a citizen, not the other way around.
Second, it is not necessary to prove your identity in order to prove your citizenship. It's entirely possible to build a system that can reliably identify citizens while providing anonymity. My name and birth date do not prove my citizenship. A card that said "US Citizen" and had the same sort of headshot you'd find in a passport would be equally secure and totally anonymous.
Finally, a manual visual comparison of an outdated, 1" headshot on commodity plastic card with limited, non-interactive anti-counterfeiting measures hardly proves my identity, let alone citizenship. If we're going to pretend the knowing someone's identity provides any valuable security we should at least solve the purely technical problem of reliably knowing that a person's credentials match their identity.
First, I don't think it's reasonable. I believe that requiring ID to do anything other than execute a contract or license or other required registration is unreasonable. And if there were a commonly available way to anonymously authenticate people it would be overkill of licenses and contracts as well. Seriously, in order to drive I should only need to show that the person in the driver's seat has a valid license; I should not need to prove who that person is, or any other fact about them.
Second, even back when the FAA was only requiring simple metal detector searches the supreme court could hardly swallow it. Their ruling specifically noted that it was only reasonably if everyone was searched equally and they were only looking for things that posed an eminent risk to the flight.
My desire to travel anonymously is, at best, suspicious (and I'd argue it isn't even that) -- it certainly isn't evidence of an eminent risk to the flight. Therefore the search is unreasonable, even under the strained ruling that allowed pre-boarding searches in the first place.
No one tried nitro again because it's highly contact sensitive unless you freeze it -- one bad bump on the card ride over and you never make it to the plane.
Granted it does freeze at like 50 F, but it's particularly sensitive to impact as it thaws -- nitro used to be shipped frozen for safety during transport, but the thawing process was so dangerous that even under controlled conditions there were more injuries from thawing than there were from shipping in liquid form.
I know physical safety is not high on the list of a suicide bomber's priorities, but they do generally at least want to make it to their target before blowing up, and nitro is simply too unpredictable to ensure accurate delivery.
But with USB there's absolutely no way I can tell the difference between a dongle, and a bit of software that attaches to the USB chain. Or a single uber-dongle that emulates an number of other dongles after cloning from the original/loading a saved config. With parallel/ADB/serial dongles it was at least moderately hard, but with USB it's trivial.
At the very least the USB dongle would have to do something sort of calculations to provide authentication using a cryptographic authentication system. Certainly you could build dongles with appropriate computing power, they quickly become expensive. And you still have to deal with the possibility of simply cracking the game to bypass the check and skip to the "yep, authenticated" portion -- the USB device would have to provide some bit of data that was necessary to execute the machine code but different from use-to-use, which is a non-trivial problem all on its own.
Not to mention that no one would just use the USB block device driver -- they would all require that you install slightly different, conflicting drivers to read their USB dongles.
Are you suggesting that in the not-50s (i.e. now) not-very-very-few kids (i.e. a non-trivial portion of kids) would take "Kill the fucking cop" songs to heart? Because I think we're short a few thousand cop killings for that to be statistically accurate.
And if that's not what you're suggesting I don't understand the point of the last line of your post, other a somewhat more topical (though no more useful) "kids these days" complaint.
No, but they started on Mac, you know, the environment that is supposedly intentionally hard to port from, and were then ported to other environments. Moreover they eventually spawn clones like OpenOffice, some of which are open source. I realize that clones aren't strictly ports, but it's still software that originated on a Mac and is now in wide use on a variety of platforms.
You don't have to like Apple, or use a Mac. But it's ridiculous to claim that Apple intentionally tries to make porting difficult. They may not be interested in making porting easy (though I'm not sure that's an entirely firm point in the first place) but you're assigning intent and malice to a situation that can be adequately described by simple apathy.
The system as a whole *did* know the reading was bogus. The control/safety system shut down because it stopped getting "safe" indications from the monitoring/input system. It seems pretty clear that the input system itself correctly logged the reason for the error.
The interface to the control system for the tank level doesn't (or at least shouldn't) have an entire separate "error" parameter -- it probably takes a simple numeric value from the input system.
The input software knows when the reading are bogus or missing. In that case it either stops sending input, which would presumably trigger a watchdog in the control system, or it sends data that indicates a worst-case scenario. with which the control system can do whatever it does in a worst-case scenario.
The control system itself doesn't care why there is or may not be safe input parameters, it only cares that it cannot rely on the input it needs for safe operation. Giving it any more information just adds code and interface complexity to safety-critical software.
Here's the system as implemented: level = tank.getLevel() if (level < SANE_MIN || level > SANE_MAX)
level = 0 control.input.set(TANK_LEVEL, level)
Here's the system you describe: error = 1 level = tank.getLevel() if (level > SANE_MIN && level < SANE_MAX)
error = 0 control.input.set(TANK_LEVEL, level, error)
The later makes the safety-critical control software more complex, with more test cases and more input parameters, none of which add any value to the safe operation of the control system. The error parameter potentially allows for operation during transient errors, but that's a decision you can make in other ways, without adding interface complexity.
The only inconvenience of the simpler interface is that you have to check the logs from the input device in addition to the control device to determine why the error occurred. And please don't argue that consolidated error logging is worth extra code complexity -- that's probably not even true in a web app, let alone a human-safety control system.
I agree it would be useful to have better client-side protection, but I don't understand how this system could possible make things worse.
Currently the options for limiting the scope of JavaScript are: 1. Turn JS off 2. Prevent certain files from loads (i.e./etc/hosts or the like)
This does not interfere with either of those, and adds: 3. Allow site administrators explicitly list allowed scripts/domains and block all others.
You can still turn off JS, and you can still prevent certain files from loads. If you came up with some other system to let users decide what JS to run or not (like NoScript), that would still work too. This isn't a system to override your personal settings and force scripts to run, it's just another layer of protection applied before your personal settings, and to help people that can't or don't take the kind of additional protection steps you do.
I'm not a fan of the specific policies of NCLB, but I don't understand how measuring a schools performance with standardized testing is a bad plan. The current implementation may not be ideal, but the theory seems sound to me.
I want standardized testing to make teachers "teach the test" -- so long as the test covers all the material we want students to understand, that's an ideal outcome. It gives schools and teachers and objective reference to determine if their curriculum is complete and accurate. And the scores give us feedback about the relative performance of schools and teachers, so we can determine when we fail to meet academic goals, and investigate the difference between schools and teachers with different success rates.
It's not like you have to shove all this testing into 2 hours in the last week of class -- a situation where you couldn't possible cover all the requisite information. We could construct a series of short, standardized tests to be given through the year in various subjects, as part of normal classwork. Combine those with more comprehensive tests given on a less frequent basis to ensure retention. You know, just like teachers should be (and for the most part are) doing anyway, except designed by people who are both experts in the subject area and who have experience with statistics and test design.
What letter of the law makes downloading movies I don't own illegal? I'd really appreciate a reference to the USC chapter and section.
It's also not clear to me that I'm allowed to time-shift my rented DVD, due to the nature of the rental agreement. The original time-shifting arguments with a VCR had to do with broadcast TV, which is by its nature time-dependent, and cannot be subject to standard rental terms. But DVDs have the same content over time, and my rental entitles me to use for a specific period, just like renting an apartment entitles use for a specific period.
Now, if you've got a clever lawyer there may be some room for a legal challenge on the same sort of time-shifting grounds, but to the best of my knowledge no such challenge has ever been heard in court. Until and unless it is I wouldn't go around telling people that it's safe to "time-shift" their DVD rentals.
Or get a much slower system that *can't* play 1080p but can record the incoming MPEG-2 stream in real time. We're talking sub-500 MHz here, which you should be able to do on a very small power budget.
Then get a faster system for playback, and optionally transcoding -- schedule the faster machine to turn on every night at 3 AM, check for videos to transcode, and shut down when there aren't any left.
You could also add a little scripting to the low-power machine to have it turn on and off automatically. At the end of each recording, check when the next recording will start. If it's more than a few minutes in the future, set the machine to power-on 5 minutes before that time, then shutdown.
I know people are still confused by the magic of IPSec, but seriously, UDP over IPSec is a vastly superior way to secure RTP in any situation where packets might be dropped or re-ordered. SSL+TCP+RTP might work on a LAN with lots of bandwidth to spare, but it just doesn't work across the Internet.
I used to have an IPSec bridge to the office, with RTP running over UDP on that bridge. Everything worked great. Now my company has turned off end-user IPSec, and requires use of the Cisco SSL/TCP-based VPN client. I'm now forced to forward all calls to my cell, because phone calls over the new VPN stutter like nobody's business about 40% of the time.
There's a CIFS server for linux -- it's called Samba.
The bit being deprecated is the SMB network file system, not Samba (which isn't part of the kernel in the first place). The CIFS network file system now supported in the kernel is fully compatible with Samba file servers, and Samba file servers require neither SMB NFS nor CIFS NFS to be enabled in the kernel.
Is that like "only the right (and powerful) people spend money on something as frivolous as not having to butcher their own animals"?
There are legitimate reasons you might not want an automatic transmission -- you might like the additional control, better fuel economy, improved failure modes, etc. -- but dismissing it as "frivolous" just makes you sound envious of people who can afford a lifestyle you'd like for yourself.
I live in the middle of Iowa, and I consider car alarms an annoyance at best, and given the right circumstances, even a criminal nuisance.
The people next door have a (presumably broken) car alarm that goes off for no reason at least 4 days a week. The thing is parked in a carport with no one around, and it just sets out honking and flashing. The owners don't even notice, but the thing drives me nuts because it's parked right outside my office window. The alarm shuts itself off after about 5 minutes, but it frequently goes off again within the next 10, and often cycles like that for hours at a time.
An Internet-based service where you can post any document you want that says anything you want? I bet my web hosting company would love to sell that idea.
Seriously, ignoring the fact that you've just described "The World Wide Web" as some yet-unrealized boogieman, I don't see what the problem is. I'm free to make credit-granting decisions based on essentially any criteria I want, except those few classes granted special legal protection. But "favorite shoe color" is not a protected class, and if I want to avoid issuing loans to people with purple shoes I am free to make that choice, even if it's based on anonymous Internet reports.
Hard links aren't as nice as a good block/stripe-level snapshot system, but the essentially are a filesystem-level snapshot, sans the non-atomic nature of their creation. Frankly I don't see how a filesystem-level snapshot would help with large files. Each snapshot with a different file version would need a copy of the entire file.
Using a lower-level snapshot (block/stripe level) would be more useful, as only the changed blocks/stripes would need to be stored. And more advanced volume management lets you break free from the archaic partitioning scheme used for block-level access, which is also a good thing. So if you wanted to complain about how Apple should support something like linux's LVM I'd be with you 100%.
That being said, Apple does have some support for advanced volume management -- disk images are treated as full-fledged block devices, and can be used with all the standard tools, including software RAID and the like. And they also support shadow-writes, so you can mount an image read-write using a secondary file to store overrides without touching the original data. And you can save the override files between sessions to support multiple versions. I'm even pretty sure you can mount the same image with concurrent sessions using different override files. So the volume-access layer in OS X already supports about 85% of what you'd need, it just doesn't support it for real (non-image) block devices, or merging old snapshots back into the main data set.
I wouldn't overestimate them either. The amount of time required to execute and exhaustive search is well-defined, and for mid-sized PGP keys is infeasible even assuming the NSA has access to hardware 10^1000 times faster than the rest of us (which seems unlikely all by itself).
Now, it's possible that the NSA is aware of some weakness in the public-key system itself, and therefore does not need to undertake an exhaustive key search, but that isn't the scenario laid out above.
I generally agree, and have recently switched from qmail-ldap to postfix myself. But keep the historical context in mind. Back in say 1998, postfix wasn't an option (version 1.0 in 2001), and qmail was waaaaaay better than sendmail.
Also keep in mind that qmail proper is 10 years old, and things like RFC 2822 didn't exist when it was written. qmail-ldap provides a much more modern view on email -- including all the goodies like TLS/SSL support, pre-acceptance address verification, etc. -- to the same basic structure.
If you'd ever been depressed (or fat or a smoker, etc.), you know that "knowing how" and "being able to execute" are totally unrelated.
And some sort-term advise for the grandparent: Hard liquor. Fewer calories. Less filling. Better drunk/dollar value, particularly if you don't make "tastes great" a requirement.
Slashdot Mirror
Now you've learned the importance of archiving, in addition to backups.
it's possible for a person who first gets cc'ed 15 replies into the conversation to start by reading the immediate message that he's supposed to comment on, and then read on down (if he cares) for as much context as he needs to figure out what that original issue was about (and then stop).
Only if you can read backwards. Otherwise you have to manually parse all the message headers and footers, searching for start and stop points, and then go back to read top-to-bottom like most humans. Wouldn't it be less work simply to scroll to the bottom once, read the last message, and then start scanning in-order from the beginning if you wanted more context? Or, you know, just start at the top and read down -- if people appropriately edited out old content you probably wouldn't feel the need to skip reading things that were sent to you.
First, asking who you are is a search. And you're generally welcome to refuse such searches. Apparently just not at airports.
Second, fishing licenses, library cards, passports and driver's licenses do not need to prove your identity. They need to prove your authorization to fish, check out books, enter the country and operate a vehicle respectively. They may contain information about your identity as a matter of convention or convenience, but that is not their purpose.
When you're fishing the ranger only needs to check that the person with a line in the water is the person to whom the fishing license was issued. And when they are issuing the license they only need to check that you meet the requirement -- in most cases the only requirement that you're a real person, though you may get a discount for living in a certain jurisdiction, or being a certain age. It seems entirely plausible that the DNR could print a card that said "Licensed to fish until 2008-12-31. Serial number: A12-34-B56', and contained my picture, or some other piece of authenticating information (ideally something totally anonymous, like my public key). Then the ranger could validate that I am the licensee, and could even check the serial number against the database to be sure the authorization hadn't been withdrawn, or the card modified. And at no point in this process would anyone need to know my name, or any other identifying information.
So, if the TSA wanted to issue me a card that said "Not a terrorist, OK to fly" and had my picture on it, I'd be happy to show them that. But they don't need to know who I am, and they don't need to be able to tie me to any other databases or identifying information. The fact that I want to leave my immediate geographic area does not make me suspicious. Millions upon millions of people who aren't committing crimes (let alone flight-related crimes) travel every year; that by it's nature makes travel a "typical" behavior, which by definition is not suspicious.
Frankly I don't understand why they can demand credentials even *with* cause. I mean, it's expedient, but I don't see how the justice system falls apart if you can't immediately ascertain someone's name and birthdate. In the modern era adults regularly carry government-issued credentials with them. But that wasn't always the case, and things seemed to work out okay.
Moreover I think it's absurd that your driver's license contains anything other than a number that can be used to tie your original test results to some sort of authentication system (we currently use a picture, there are better and more anonymous alternatives) and to tie driving-related court records to a specific licensee. In a traffic stop the cop needs to know that the person driving has been authorized to do so, and that the authorization has not been withdrawn. He does not need to know my name, birthdate, or any other identifying information.
And after the traffic stop, even if I am citied, the government does not have a legitimate need to track any additional information in relation to my traffic violation. You should not be able to determine where I live, when I was born, what personal or real property I own, or lookup other non-traffic convictions simply by knowing my driver's license number. We've allowed this to happen because it's convenient for law enforcement, but that's a pretty weak defense against the potential (and demonstrable) abuse.
It's not just drivers licensing either. if you're arrested for any reason, even if you are never charged and are released within minutes of being booked, the police will keep your fingerprints, DNA, and anything else they can get their hands on. They'll tie that information to your real and personal property registrations, your address, name, birthdate, drivers license, social security, and phone numbers. In some jurisdictions you can request that these records be destroyed, but it doesn't happen automatically. And in most jurisdictions you have no way to remove all this tracking information from law enforcement databases. There is simply no need for the government to keep those records; they are collected and stored simply as a convenience to law enforcement, to make prosecution more efficient. Not more just mind you -- I could tolerate some of the tracking if I believed it improved justice -- just more efficient.
First, the government is under an obligation to prove I am not a citizen, not the other way around.
Second, it is not necessary to prove your identity in order to prove your citizenship. It's entirely possible to build a system that can reliably identify citizens while providing anonymity. My name and birth date do not prove my citizenship. A card that said "US Citizen" and had the same sort of headshot you'd find in a passport would be equally secure and totally anonymous.
Finally, a manual visual comparison of an outdated, 1" headshot on commodity plastic card with limited, non-interactive anti-counterfeiting measures hardly proves my identity, let alone citizenship. If we're going to pretend the knowing someone's identity provides any valuable security we should at least solve the purely technical problem of reliably knowing that a person's credentials match their identity.
First, I don't think it's reasonable. I believe that requiring ID to do anything other than execute a contract or license or other required registration is unreasonable. And if there were a commonly available way to anonymously authenticate people it would be overkill of licenses and contracts as well. Seriously, in order to drive I should only need to show that the person in the driver's seat has a valid license; I should not need to prove who that person is, or any other fact about them.
Second, even back when the FAA was only requiring simple metal detector searches the supreme court could hardly swallow it. Their ruling specifically noted that it was only reasonably if everyone was searched equally and they were only looking for things that posed an eminent risk to the flight.
My desire to travel anonymously is, at best, suspicious (and I'd argue it isn't even that) -- it certainly isn't evidence of an eminent risk to the flight. Therefore the search is unreasonable, even under the strained ruling that allowed pre-boarding searches in the first place.
No one tried nitro again because it's highly contact sensitive unless you freeze it -- one bad bump on the card ride over and you never make it to the plane.
Granted it does freeze at like 50 F, but it's particularly sensitive to impact as it thaws -- nitro used to be shipped frozen for safety during transport, but the thawing process was so dangerous that even under controlled conditions there were more injuries from thawing than there were from shipping in liquid form.
I know physical safety is not high on the list of a suicide bomber's priorities, but they do generally at least want to make it to their target before blowing up, and nitro is simply too unpredictable to ensure accurate delivery.
But with USB there's absolutely no way I can tell the difference between a dongle, and a bit of software that attaches to the USB chain. Or a single uber-dongle that emulates an number of other dongles after cloning from the original/loading a saved config. With parallel/ADB/serial dongles it was at least moderately hard, but with USB it's trivial.
At the very least the USB dongle would have to do something sort of calculations to provide authentication using a cryptographic authentication system. Certainly you could build dongles with appropriate computing power, they quickly become expensive. And you still have to deal with the possibility of simply cracking the game to bypass the check and skip to the "yep, authenticated" portion -- the USB device would have to provide some bit of data that was necessary to execute the machine code but different from use-to-use, which is a non-trivial problem all on its own.
Not to mention that no one would just use the USB block device driver -- they would all require that you install slightly different, conflicting drivers to read their USB dongles.
Are you suggesting that in the not-50s (i.e. now) not-very-very-few kids (i.e. a non-trivial portion of kids) would take "Kill the fucking cop" songs to heart? Because I think we're short a few thousand cop killings for that to be statistically accurate.
And if that's not what you're suggesting I don't understand the point of the last line of your post, other a somewhat more topical (though no more useful) "kids these days" complaint.
No, but they started on Mac, you know, the environment that is supposedly intentionally hard to port from, and were then ported to other environments. Moreover they eventually spawn clones like OpenOffice, some of which are open source. I realize that clones aren't strictly ports, but it's still software that originated on a Mac and is now in wide use on a variety of platforms.
You don't have to like Apple, or use a Mac. But it's ridiculous to claim that Apple intentionally tries to make porting difficult. They may not be interested in making porting easy (though I'm not sure that's an entirely firm point in the first place) but you're assigning intent and malice to a situation that can be adequately described by simple apathy.
The system as a whole *did* know the reading was bogus. The control/safety system shut down because it stopped getting "safe" indications from the monitoring/input system. It seems pretty clear that the input system itself correctly logged the reason for the error.
The interface to the control system for the tank level doesn't (or at least shouldn't) have an entire separate "error" parameter -- it probably takes a simple numeric value from the input system.
The input software knows when the reading are bogus or missing. In that case it either stops sending input, which would presumably trigger a watchdog in the control system, or it sends data that indicates a worst-case scenario. with which the control system can do whatever it does in a worst-case scenario.
The control system itself doesn't care why there is or may not be safe input parameters, it only cares that it cannot rely on the input it needs for safe operation. Giving it any more information just adds code and interface complexity to safety-critical software.
Here's the system as implemented:
level = tank.getLevel()
if (level < SANE_MIN || level > SANE_MAX)
level = 0
control.input.set(TANK_LEVEL, level)
Here's the system you describe:
error = 1
level = tank.getLevel()
if (level > SANE_MIN && level < SANE_MAX)
error = 0
control.input.set(TANK_LEVEL, level, error)
The later makes the safety-critical control software more complex, with more test cases and more input parameters, none of which add any value to the safe operation of the control system. The error parameter potentially allows for operation during transient errors, but that's a decision you can make in other ways, without adding interface complexity.
The only inconvenience of the simpler interface is that you have to check the logs from the input device in addition to the control device to determine why the error occurred. And please don't argue that consolidated error logging is worth extra code complexity -- that's probably not even true in a web app, let alone a human-safety control system.
Actually a lot of plumbers do electrical work. And HVAC work. Haven't you ever seen a van for "AAA Heating, Plumbing and Electrical"?
I agree it would be useful to have better client-side protection, but I don't understand how this system could possible make things worse.
/etc/hosts or the like)
Currently the options for limiting the scope of JavaScript are:
1. Turn JS off
2. Prevent certain files from loads (i.e.
This does not interfere with either of those, and adds:
3. Allow site administrators explicitly list allowed scripts/domains and block all others.
You can still turn off JS, and you can still prevent certain files from loads. If you came up with some other system to let users decide what JS to run or not (like NoScript), that would still work too. This isn't a system to override your personal settings and force scripts to run, it's just another layer of protection applied before your personal settings, and to help people that can't or don't take the kind of additional protection steps you do.
I'm not a fan of the specific policies of NCLB, but I don't understand how measuring a schools performance with standardized testing is a bad plan. The current implementation may not be ideal, but the theory seems sound to me.
I want standardized testing to make teachers "teach the test" -- so long as the test covers all the material we want students to understand, that's an ideal outcome. It gives schools and teachers and objective reference to determine if their curriculum is complete and accurate. And the scores give us feedback about the relative performance of schools and teachers, so we can determine when we fail to meet academic goals, and investigate the difference between schools and teachers with different success rates.
It's not like you have to shove all this testing into 2 hours in the last week of class -- a situation where you couldn't possible cover all the requisite information. We could construct a series of short, standardized tests to be given through the year in various subjects, as part of normal classwork. Combine those with more comprehensive tests given on a less frequent basis to ensure retention. You know, just like teachers should be (and for the most part are) doing anyway, except designed by people who are both experts in the subject area and who have experience with statistics and test design.
What letter of the law makes downloading movies I don't own illegal? I'd really appreciate a reference to the USC chapter and section.
It's also not clear to me that I'm allowed to time-shift my rented DVD, due to the nature of the rental agreement. The original time-shifting arguments with a VCR had to do with broadcast TV, which is by its nature time-dependent, and cannot be subject to standard rental terms. But DVDs have the same content over time, and my rental entitles me to use for a specific period, just like renting an apartment entitles use for a specific period.
Now, if you've got a clever lawyer there may be some room for a legal challenge on the same sort of time-shifting grounds, but to the best of my knowledge no such challenge has ever been heard in court. Until and unless it is I wouldn't go around telling people that it's safe to "time-shift" their DVD rentals.
Or get a much slower system that *can't* play 1080p but can record the incoming MPEG-2 stream in real time. We're talking sub-500 MHz here, which you should be able to do on a very small power budget.
Then get a faster system for playback, and optionally transcoding -- schedule the faster machine to turn on every night at 3 AM, check for videos to transcode, and shut down when there aren't any left.
You could also add a little scripting to the low-power machine to have it turn on and off automatically. At the end of each recording, check when the next recording will start. If it's more than a few minutes in the future, set the machine to power-on 5 minutes before that time, then shutdown.
I know people are still confused by the magic of IPSec, but seriously, UDP over IPSec is a vastly superior way to secure RTP in any situation where packets might be dropped or re-ordered. SSL+TCP+RTP might work on a LAN with lots of bandwidth to spare, but it just doesn't work across the Internet.
I used to have an IPSec bridge to the office, with RTP running over UDP on that bridge. Everything worked great. Now my company has turned off end-user IPSec, and requires use of the Cisco SSL/TCP-based VPN client. I'm now forced to forward all calls to my cell, because phone calls over the new VPN stutter like nobody's business about 40% of the time.
There's a CIFS server for linux -- it's called Samba.
The bit being deprecated is the SMB network file system, not Samba (which isn't part of the kernel in the first place). The CIFS network file system now supported in the kernel is fully compatible with Samba file servers, and Samba file servers require neither SMB NFS nor CIFS NFS to be enabled in the kernel.
Is that like "only the right (and powerful) people spend money on something as frivolous as not having to butcher their own animals"?
There are legitimate reasons you might not want an automatic transmission -- you might like the additional control, better fuel economy, improved failure modes, etc. -- but dismissing it as "frivolous" just makes you sound envious of people who can afford a lifestyle you'd like for yourself.
I live in the middle of Iowa, and I consider car alarms an annoyance at best, and given the right circumstances, even a criminal nuisance.
The people next door have a (presumably broken) car alarm that goes off for no reason at least 4 days a week. The thing is parked in a carport with no one around, and it just sets out honking and flashing. The owners don't even notice, but the thing drives me nuts because it's parked right outside my office window. The alarm shuts itself off after about 5 minutes, but it frequently goes off again within the next 10, and often cycles like that for hours at a time.
An Internet-based service where you can post any document you want that says anything you want? I bet my web hosting company would love to sell that idea.
Seriously, ignoring the fact that you've just described "The World Wide Web" as some yet-unrealized boogieman, I don't see what the problem is. I'm free to make credit-granting decisions based on essentially any criteria I want, except those few classes granted special legal protection. But "favorite shoe color" is not a protected class, and if I want to avoid issuing loans to people with purple shoes I am free to make that choice, even if it's based on anonymous Internet reports.
Hard links aren't as nice as a good block/stripe-level snapshot system, but the essentially are a filesystem-level snapshot, sans the non-atomic nature of their creation. Frankly I don't see how a filesystem-level snapshot would help with large files. Each snapshot with a different file version would need a copy of the entire file.
Using a lower-level snapshot (block/stripe level) would be more useful, as only the changed blocks/stripes would need to be stored. And more advanced volume management lets you break free from the archaic partitioning scheme used for block-level access, which is also a good thing. So if you wanted to complain about how Apple should support something like linux's LVM I'd be with you 100%.
That being said, Apple does have some support for advanced volume management -- disk images are treated as full-fledged block devices, and can be used with all the standard tools, including software RAID and the like. And they also support shadow-writes, so you can mount an image read-write using a secondary file to store overrides without touching the original data. And you can save the override files between sessions to support multiple versions. I'm even pretty sure you can mount the same image with concurrent sessions using different override files. So the volume-access layer in OS X already supports about 85% of what you'd need, it just doesn't support it for real (non-image) block devices, or merging old snapshots back into the main data set.
I wouldn't overestimate them either. The amount of time required to execute and exhaustive search is well-defined, and for mid-sized PGP keys is infeasible even assuming the NSA has access to hardware 10^1000 times faster than the rest of us (which seems unlikely all by itself).
Now, it's possible that the NSA is aware of some weakness in the public-key system itself, and therefore does not need to undertake an exhaustive key search, but that isn't the scenario laid out above.
I generally agree, and have recently switched from qmail-ldap to postfix myself. But keep the historical context in mind. Back in say 1998, postfix wasn't an option (version 1.0 in 2001), and qmail was waaaaaay better than sendmail.
Also keep in mind that qmail proper is 10 years old, and things like RFC 2822 didn't exist when it was written. qmail-ldap provides a much more modern view on email -- including all the goodies like TLS/SSL support, pre-acceptance address verification, etc. -- to the same basic structure.
If you'd ever been depressed (or fat or a smoker, etc.), you know that "knowing how" and "being able to execute" are totally unrelated.
And some sort-term advise for the grandparent: Hard liquor. Fewer calories. Less filling. Better drunk/dollar value, particularly if you don't make "tastes great" a requirement.