But that is pretty obviously a legal fiction (perhaps an unwise legal fiction)
However, there really isn't a better candidate. Barrel? Those are replaced all the time. Bolt? Ditto. Trigger assembly? More often even than bolts or barrels. Stock? Handguard? Grip?
Modern rifles are completely modular. The lower receiver was selected precisely because it's so simple and inert that there's no reason to replace it. It doesn't wear out, and you can't improve the accuracy or ergonomics or power of the gun by replacing it. It's the thing you hang the rest of the modules from -- so legally it's the gun.
With automobiles the frame is the car. With AR-style rifles, it's the lower receiver. It's something of a fiction, I suppose, but it's not like there's another piece that is a better choice, and if you don't pick some piece you end up with the Washington's hatchet problem. "This is George Washington's hatchet; the handle rotted and had to be replaced, and the head too when it rusted, but it's the original hatchet."
How about 80 miles? I picked the 40 number to assume charging only at home, then went on to mention charging both home and work. With charging in both places, an 80-mile commute is feasible with current EVs.
That's a lot less common, but I do personally know people with commutes that long. Note that you're giving ideal figures. Regenerative braking ain't 100%, so typical commute traffic is going to be hard on ideal mileage... I argue for EVs all the time for people for whom they make sense, but that just isn't everybody.
No, I'm not giving ideal figures. In ideal conditions my LEAF will go 120 miles. 80 miles is a very practical range.
While this is true, it's irrelevant for the majority of vehicle-miles driven. How many commuters live more than 40 miles from work?
That's a good question, but I know it's actually a lot. Especially in California, where we have the most people, the most cars, and the most vehicle-miles traveled. Commutes longer than 40 miles are, sadly, just not that unusual in the USA.
How about 80 miles? I picked the 40 number to assume charging only at home, then went on to mention charging both home and work. With charging in both places, an 80-mile commute is feasible with current EVs.
Yeah, a generator trailer would be awesome, and would dramatically increase the utility of an EV. It doesn't really matter for me because I need multiple vehicles anyway, but it would make EVs useful to more people.
But, unfortunately, energy density of batteries are much less efficient than ethanol, and so is charging ability. I can't do as much as fast with electric cars as ethanol cars, and until that is solved, there are far bigger problems than acreage.
While this is true, it's irrelevant for the majority of vehicle-miles driven. How many commuters live more than 40 miles from work? Given charging infrastructure in both places, current-generation EVs (like my Nissan LEAF) are perfect. Right now, an EV is a great second car for most people, and could even be an only car for many if you are willing to rent a gas burner for the occasional longer trips.
Upon reception of an HTTP request, the demo spawns a new Xen domain with LING VM and a web application written in Erlang. After serving a single request the domain simply shuts itself down and frees all resources. The whole process takes 1.5-2sec.
I think that 1 connect per 1.5-2 seconds minimum is probably impressive for a web server if its running on... well hell, I don't know, an Arduino can serve pages faster than that.
The point is elasticity, being able to very rapidly scale in response to surges of demand. If you put this in production you wouldn't have it handle only a single request per VM instance, you'd probably have each instance stay up and continue handling requests until the incoming request rate dropped below some threshold. Because starting new instances is so inexpensive, though, you could set that rate pretty aggressively, then let the pool of active servers expand and contract dynamically (and very rapidly) in response to the ebb and flow of demand.
In short, site operators have to perform at least some level of self-policing in order to obtain protection under OCILLA.
Cite?
It's been a few years since I read the law, but I don't recall any requirements for pro-active policing, only that operators take down allegedly infringing material when presented with a takedown notice, and that they may put it back up if they receive a counter-notice.
it's not right to treat any person (male or female) that way.
This, to me, is the oddest part of this whole discussion.
Adria, and many of the commenters, keep casting this as an incident of sexism. As far as I can tell there was nothing in the comments that was in any way sexist, except perhaps that the discussion of "big dongles" could be construed as degrading to men.
But it's seen in a sexist light... and the reason it is, I think, is a sexist assumption underlying all of the comments, including Adria's own, namely that women are more sensitive to discussions that touch upon sexuality than men are.
Honestly, I think I'm more offended by it than most people, of either gender. But the assumption is that I should not be bothered because I'm a man, and it should be avoided when women are around because the're women. And women often seem to support and maintain this particular bit of sexism at least as much as men do.
There is no clear litmus test that defines 'this is acceptable' but 'that is not acceptable' and the boundary can vary from person to person and how they are feeling on the day.
This is true, and it's why the first reaction to an offense should always be to point out that it's offensive -- because otherwise the offender may not even realize that they're being offensive. Actually, pointing out the offense to the offender should probably be the second reaction. The first should be an evaluation of whether or not the offense is sufficient to justify responding to it. Because people from many different backgrounds see things differently, and it is impossible to define a clear set of rules for acceptable behavior.
That's what bothers me most about this case. From her tweets it's clear that Adria isn't above a little crotch humor herself, and yet she went nuclear on the guys at PyCon.
I should be clear that I'm talking about general offensiveness, not about sexism or other forms of personal degradation or humiliation. But in this case there was nothing sexist about the jokes. Sexual, yes, sexist, no. Also, I should be clear that if something really offends you, you can and should speak up about it, and absolutely should expect it to be addressed.
What sort of security concerns are you thinking of?
An attacker who controls one of the paths can obviously modify, replace, delay or delete portions of the stream which are multiplexed onto that path. Such an attacker could probably perform a DoS that would shut down the entire stream (disclaimer: I haven't read the details). But of course ordinary TCP is subject to all the same attacks, if the attacker has control of the path that carries it. In many cases an attacker without control of the path can also execute DoS attacks against TCP (e.g. sending RSTs).
I'm not saying there aren't any new vulnerabilities exposed, but I'm not seeing where they would lie. TCP is not secure in any useful sense, so it's hard to see how MTCP could be worse.
Doesn't SCTP provide for these scenarios (and many more)?
No.
SCTP supports multiple paths between endpoints, but doesn't use them simultaneously. Rather, it picks a primary path to use for data transfers and has the ability to fail over to an alternate path in the event the primary fails.
A quick glance at the MTCP RFC shows that it is essentially multiplexing packets over n separate TCP streams (called subflows). It's the responsibility of the TCP/IP stack (in the OS, generally) to make this multiplexing transparent to the application, so the application only sees one stream.
A map and watch will tell you how far you went and how long it took.
Unless your route was fairly straight, determining the length of your ride with a map will be both tedious and inaccurate.
And if you're interested in details like how much time you spent stopped vs riding, what your speed was at various points on your route (e.g. are you getting faster at climbing that hill? how much?), then tracking the data with only a watch will be both difficult and undoubtedly you'll find yourself wanting information about old rides that you didn't think to collect at the time.
Having a perpetual log of detailed, GPS-tracked data makes it possible to learn a lot more about your progress. Of course, you personally may not care about that. Now. But others do.
Personally, I mostly want the freedom to take varied and complex routes while still getting accurate, automatically-recorded distance logs so I can check my mileage logged against my goals. With a smartphone I tap an icon to start, tap an icon to end, and everything else just happens automatically; I get periodic e-mails telling me how I'm tracking against my goals. This is worth something, even if you're not a nerd (which, admittedly, I am).
I'm looking for click-in standardized replacement batteries. I pull up to a station. Unclick my batteries and put them in the charger and immediately click in replacements and leave. I'm not waiting around for 30 minutes to charge my car.
Swappable batteries (and high-speed chargers) are a solution for a problem that only occurs in a very small percentage of typical driving. Most vehicles spend a lot of time parked, and except for occasional longer trips (once every few weeks, or months) only drive fairly short distances. Commuting, running to the grocery store, taking the kids to school, that sort of thing. For that sort of driving, the answer isn't to use fast chargers or swap batteries, it's just to plug the car in whenever it's parked. The cost and complexity of the infrastructure required for swappable batteries just doesn't make sense for solving what's essentially a corner case for most people -- not all, mind you. People who regularly drive 400+ miles non-stop will continue to need combustion engines.
I would like to know if Google employees are let go every time a project is cancelled.
I think it's not uncommon that the employees have already drifted to other projects and are maintaining it as a 20% project even before a project is cancelled. But if they haven't they'll certainly simply find another team after the cancellation. Finding a different team in Google is very easy... in fact it's a rare presentation at the weekly company-wide meetings that doesn't end with the presenting team saying "BTW, we're hiring". In general, Google has a hard time finding enough people to staff all of its projects and most teams are always looking.
Forget CO2 levels. This is a helpful excuse to rendezvous with your lady/fellow and figure out *some* way to amuse yourselves for an hour in the dark.
"Hey, it's for the good of the planet. Or whatever."
That's an easy one. Our tablets have backlit screens and the batteries can handle an hour, no sweat.
You mean a cloud service in "limited preview" is much faster than a cloud server open to the public and heavily used?
There much be some fancy engineering behind the scenes to make a lightly used service run faster than a heavily used one.
I want to see the benchmarks after GCE is open to the public.
They'll be the same -- or maybe better, as the service continues to improve.
GCE may be lightly used at present, but it has a massive competitor for compute resources: Google's own products. Even when GCE becomes very widely-used, it will still be small potatoes compared to Google's own compute load.
Oil will tend to get more and more scarce and expensive. Market invisible hand seems unable to do anything about it
If the market can't do anything about it, why will it get more expensive?
The increase in price that comes with scarcity, and the resulting incentive that drives increased focus on alternatives is the "invisible hand" of the market at work.
In the last three months, our company has hired THREE H1B employees, one being a programmer. They had to post the jobs, so I got to see the salary ranges.
Can we assume you've reported your company's illegal behavior to the INS?
Slashdot Mirror
But that is pretty obviously a legal fiction (perhaps an unwise legal fiction)
However, there really isn't a better candidate. Barrel? Those are replaced all the time. Bolt? Ditto. Trigger assembly? More often even than bolts or barrels. Stock? Handguard? Grip?
Modern rifles are completely modular. The lower receiver was selected precisely because it's so simple and inert that there's no reason to replace it. It doesn't wear out, and you can't improve the accuracy or ergonomics or power of the gun by replacing it. It's the thing you hang the rest of the modules from -- so legally it's the gun.
With automobiles the frame is the car. With AR-style rifles, it's the lower receiver. It's something of a fiction, I suppose, but it's not like there's another piece that is a better choice, and if you don't pick some piece you end up with the Washington's hatchet problem. "This is George Washington's hatchet; the handle rotted and had to be replaced, and the head too when it rusted, but it's the original hatchet."
How about 80 miles? I picked the 40 number to assume charging only at home, then went on to mention charging both home and work. With charging in both places, an 80-mile commute is feasible with current EVs.
That's a lot less common, but I do personally know people with commutes that long. Note that you're giving ideal figures. Regenerative braking ain't 100%, so typical commute traffic is going to be hard on ideal mileage... I argue for EVs all the time for people for whom they make sense, but that just isn't everybody.
No, I'm not giving ideal figures. In ideal conditions my LEAF will go 120 miles. 80 miles is a very practical range.
While this is true, it's irrelevant for the majority of vehicle-miles driven. How many commuters live more than 40 miles from work?
That's a good question, but I know it's actually a lot. Especially in California, where we have the most people, the most cars, and the most vehicle-miles traveled. Commutes longer than 40 miles are, sadly, just not that unusual in the USA.
How about 80 miles? I picked the 40 number to assume charging only at home, then went on to mention charging both home and work. With charging in both places, an 80-mile commute is feasible with current EVs.
Yeah, a generator trailer would be awesome, and would dramatically increase the utility of an EV. It doesn't really matter for me because I need multiple vehicles anyway, but it would make EVs useful to more people.
But, unfortunately, energy density of batteries are much less efficient than ethanol, and so is charging ability. I can't do as much as fast with electric cars as ethanol cars, and until that is solved, there are far bigger problems than acreage.
While this is true, it's irrelevant for the majority of vehicle-miles driven. How many commuters live more than 40 miles from work? Given charging infrastructure in both places, current-generation EVs (like my Nissan LEAF) are perfect. Right now, an EV is a great second car for most people, and could even be an only car for many if you are willing to rent a gas burner for the occasional longer trips.
Upon reception of an HTTP request, the demo spawns a new Xen domain with LING VM and a web application written in Erlang. After serving a single request the domain simply shuts itself down and frees all resources. The whole process takes 1.5-2sec.
I think that 1 connect per 1.5-2 seconds minimum is probably impressive for a web server if its running on ... well hell, I don't know, an Arduino can serve pages faster than that.
The point is elasticity, being able to very rapidly scale in response to surges of demand. If you put this in production you wouldn't have it handle only a single request per VM instance, you'd probably have each instance stay up and continue handling requests until the incoming request rate dropped below some threshold. Because starting new instances is so inexpensive, though, you could set that rate pretty aggressively, then let the pool of active servers expand and contract dynamically (and very rapidly) in response to the ebb and flow of demand.
In short, site operators have to perform at least some level of self-policing in order to obtain protection under OCILLA.
Cite?
It's been a few years since I read the law, but I don't recall any requirements for pro-active policing, only that operators take down allegedly infringing material when presented with a takedown notice, and that they may put it back up if they receive a counter-notice.
it's not right to treat any person (male or female) that way.
This, to me, is the oddest part of this whole discussion.
Adria, and many of the commenters, keep casting this as an incident of sexism. As far as I can tell there was nothing in the comments that was in any way sexist, except perhaps that the discussion of "big dongles" could be construed as degrading to men.
But it's seen in a sexist light... and the reason it is, I think, is a sexist assumption underlying all of the comments, including Adria's own, namely that women are more sensitive to discussions that touch upon sexuality than men are.
Honestly, I think I'm more offended by it than most people, of either gender. But the assumption is that I should not be bothered because I'm a man, and it should be avoided when women are around because the're women. And women often seem to support and maintain this particular bit of sexism at least as much as men do.
There is no clear litmus test that defines 'this is acceptable' but 'that is not acceptable' and the boundary can vary from person to person and how they are feeling on the day.
This is true, and it's why the first reaction to an offense should always be to point out that it's offensive -- because otherwise the offender may not even realize that they're being offensive. Actually, pointing out the offense to the offender should probably be the second reaction. The first should be an evaluation of whether or not the offense is sufficient to justify responding to it. Because people from many different backgrounds see things differently, and it is impossible to define a clear set of rules for acceptable behavior.
That's what bothers me most about this case. From her tweets it's clear that Adria isn't above a little crotch humor herself, and yet she went nuclear on the guys at PyCon.
I should be clear that I'm talking about general offensiveness, not about sexism or other forms of personal degradation or humiliation. But in this case there was nothing sexist about the jokes. Sexual, yes, sexist, no. Also, I should be clear that if something really offends you, you can and should speak up about it, and absolutely should expect it to be addressed.
It's like frequency hopping. The attacker will only have part of the message.
Right, but that would be a strength, not a vulnerability.
Very informative. Thank you.
What sort of security concerns are you thinking of?
An attacker who controls one of the paths can obviously modify, replace, delay or delete portions of the stream which are multiplexed onto that path. Such an attacker could probably perform a DoS that would shut down the entire stream (disclaimer: I haven't read the details). But of course ordinary TCP is subject to all the same attacks, if the attacker has control of the path that carries it. In many cases an attacker without control of the path can also execute DoS attacks against TCP (e.g. sending RSTs).
I'm not saying there aren't any new vulnerabilities exposed, but I'm not seeing where they would lie. TCP is not secure in any useful sense, so it's hard to see how MTCP could be worse.
RFC 6182 if anyone is interested.
I think RFC 6824, linked in the summary, is the more relevant RFC.
Doesn't SCTP provide for these scenarios (and many more)?
No.
SCTP supports multiple paths between endpoints, but doesn't use them simultaneously. Rather, it picks a primary path to use for data transfers and has the ability to fail over to an alternate path in the event the primary fails.
A quick glance at the MTCP RFC shows that it is essentially multiplexing packets over n separate TCP streams (called subflows). It's the responsibility of the TCP/IP stack (in the OS, generally) to make this multiplexing transparent to the application, so the application only sees one stream.
A map and watch will tell you how far you went and how long it took.
Unless your route was fairly straight, determining the length of your ride with a map will be both tedious and inaccurate.
And if you're interested in details like how much time you spent stopped vs riding, what your speed was at various points on your route (e.g. are you getting faster at climbing that hill? how much?), then tracking the data with only a watch will be both difficult and undoubtedly you'll find yourself wanting information about old rides that you didn't think to collect at the time.
Having a perpetual log of detailed, GPS-tracked data makes it possible to learn a lot more about your progress. Of course, you personally may not care about that. Now. But others do.
Personally, I mostly want the freedom to take varied and complex routes while still getting accurate, automatically-recorded distance logs so I can check my mileage logged against my goals. With a smartphone I tap an icon to start, tap an icon to end, and everything else just happens automatically; I get periodic e-mails telling me how I'm tracking against my goals. This is worth something, even if you're not a nerd (which, admittedly, I am).
I'm looking for click-in standardized replacement batteries. I pull up to a station. Unclick my batteries and put them in the charger and immediately click in replacements and leave. I'm not waiting around for 30 minutes to charge my car.
Swappable batteries (and high-speed chargers) are a solution for a problem that only occurs in a very small percentage of typical driving. Most vehicles spend a lot of time parked, and except for occasional longer trips (once every few weeks, or months) only drive fairly short distances. Commuting, running to the grocery store, taking the kids to school, that sort of thing. For that sort of driving, the answer isn't to use fast chargers or swap batteries, it's just to plug the car in whenever it's parked. The cost and complexity of the infrastructure required for swappable batteries just doesn't make sense for solving what's essentially a corner case for most people -- not all, mind you. People who regularly drive 400+ miles non-stop will continue to need combustion engines.
I would like to know if Google employees are let go every time a project is cancelled.
I think it's not uncommon that the employees have already drifted to other projects and are maintaining it as a 20% project even before a project is cancelled. But if they haven't they'll certainly simply find another team after the cancellation. Finding a different team in Google is very easy... in fact it's a rare presentation at the weekly company-wide meetings that doesn't end with the presenting team saying "BTW, we're hiring". In general, Google has a hard time finding enough people to staff all of its projects and most teams are always looking.
Forget CO2 levels. This is a helpful excuse to rendezvous with your lady/fellow and figure out *some* way to amuse yourselves for an hour in the dark. "Hey, it's for the good of the planet. Or whatever."
That's an easy one. Our tablets have backlit screens and the batteries can handle an hour, no sweat.
Cue some dude ranting about the difference between "sold" and "shipped".
Just like Amazon retail runs on the same infrastructure as EC2..
Which is a tiny fraction of the load Google manages.
I'm sorry but there's no way a web crawler is running on the same hardware as your GCE virt.
Perhaps same infrastructure but it will be partitioned resource.
I can't really go into detail but... it's the same.
It is fast because nobody is using it.
Google is. GCE runs on the same infrastructure that runs all of Google's services.
You mean a cloud service in "limited preview" is much faster than a cloud server open to the public and heavily used?
There much be some fancy engineering behind the scenes to make a lightly used service run faster than a heavily used one.
I want to see the benchmarks after GCE is open to the public.
They'll be the same -- or maybe better, as the service continues to improve.
GCE may be lightly used at present, but it has a massive competitor for compute resources: Google's own products. Even when GCE becomes very widely-used, it will still be small potatoes compared to Google's own compute load.
I am always amused when people see FFM as a feature...
It's a huge productivity booster for me. Especially because it allows me to type into a background window.
Proper command-Tab operation could partially offset the lack of FFM, but OS X doesn't have that, either.
Oil will tend to get more and more scarce and expensive. Market invisible hand seems unable to do anything about it
If the market can't do anything about it, why will it get more expensive?
The increase in price that comes with scarcity, and the resulting incentive that drives increased focus on alternatives is the "invisible hand" of the market at work.
In the last three months, our company has hired THREE H1B employees, one being a programmer. They had to post the jobs, so I got to see the salary ranges.
Can we assume you've reported your company's illegal behavior to the INS?