And you demonstrate his point perfectly. How many people know that collecting stray bird feathers lying on the ground might get them jail time? Is that an intended consequence of the law? It sounds like you know that regulation better than anybody and don't even care about any wider implications that will have surprising and awful effects, just like the bureaucrat guy in the comic.
As for the turtle example, the comic author explicitly gives the common snapping turtle as an example. A non-endangered species. State X passes a law about the snapping turtle at time T. And time T + 10 he does a vendor audit and after a lot of effort realizes that one of his vendors is now in a jurisdiction in which its illegal for them to sell him common snapping turtles. Unfortunately, the feds noticed at time T + 1. Oops, he's guilty and intent has nothing to do with it because the law isn't written that way.
I wish Google had a nice capability system that would allow you to give a revocable authorization to the app so it didn't have to know your password. They do for some things, but I don't think they do for Google Drive specifically.
They all have undiscovered holes. What makes Java any riskier than IE? What makes it any riskier than Chrome or Firefox? Is it the lack of any update strategy on Oracle's part?
Tahoe sort of achieves this in an odd way. Directories contain hashes of the file they reference instead of an inode number. This means that a Tahoe node often doesn't even know who a file really belongs to, even though it knows its length.
The main issue with block storage is this...
Suppose you modify a data section of a file in a btrfs filesystem mounted on some kind of weird encrypted block device. There will be a whole tree of blocks that get modified, all the way up to the root node. All of these blocks have to be written before the root block is, and for a small file there will be several more blocks that need updating than there are data blocks on the file.
These two issues create a big synchronization problem and a lot of extra traffic.
In contrast, a good distributed filesystem protocol that's aware of individual files can send a single message that contains some kind of identifier for the file, and the new data it should contain. This message will often be smaller than a single filesystem block, and it will also usually be compressed before it gets on the wire. Much more efficient and while there are synchronization issues between updates to individual files, within a file there aren't any.
Oh, yeah. *sheepish grin* Of course, most popular existing cloud services do not support LAFS out of the box.:-/ So yeah, you'll have to layer it on something in the manner suggested above.
BTW, doing this at a block device level is likely a very poor idea. Block devices are very difficult to get right in a distributed fashion from a synchronization standpoint. They also are likely to cause a lot of excess network traffic since the units the system deals with are poorly matched to the logical units that are actually modified. A good distributed solution to this problem will at have to know something about the fact that you have individual files to be at all reasonable to use.
The first, and most interesting, is Tahoe LAFS. It does come with a FUSE driver, so it can be mounted like a regular filesystem. It is cloud-based and redundant to a degree you choose yourself. All copies stored are encrypted, so the only person who can read them is you. I'm not sure though if fetching from more nodes than you strictly need to reconstruct your original file actually buys you anything with that system, but I think it does.
You could also use something like a mountable version of Google Drive and then layer fuse-encfs on top of it. That's not quite as secure as encrypting at the block layer. The overall shape of your directory hierarchy is available, even if the individual file names and their contents are obscured. That should probably be good enough for most purposes.
Yes, you're right. I was probably one of only 2-5 people who would've written such a letter who worked in that office. So yeah, that probably helped at least as much as style.
If you're trying to avoid having two different identities associated when you're having an IRC conversation or something, that could get really tricky.
I've thought about that. That's an interesting and tricky problem. Though, if there's a program that can detect it, that means the patterns are codified well enough that you can write a program to obscure them. The problem is, what about the program that detects these patterns that you don't know the implementation of? Will you actually be fooling it?
Of course, you have the same problem if you adopt a different writing style. Is it different enough? Is something essential slipping through?
You could use both techniques. Have a program assist you in avoiding the use of certain words when using one voice and the use of others when using a different voice.
I worked for a smallish (but not incredibly tiny, maybe 100 employees) company and wrote a letter to the CEO once. We'd been castigated by someone who'd taken over the local office because the company was doing poorly. A number of austerity measures were implemented. I did not find those to be that annoying because I realized it was either that or not have a job. But the castigation didn't sit well with me. We were in trouble because of the decisions of a few bad managers, not the behavior of average employees.
So I wrote a letter about it. He stripped my name off and presented it in an executive meeting to all the people directly under him. He asked "Why am I getting letters like this?". Everybody who worked in my office immediately knew who it was. I had a distinctive writing voice, and a strong reputation.
It did not lead to me being fired. I was actually highly respected there. It led to me being encouraged to have an honest sit-down talk with the new manager for our division (the guy who'd made the speech I wasn't happy about). I think we both came away from that meeting a lot happier about the other.
But that was a strong lesson to me. If I ever really want to be anonymous I'm going to have to purposely work on adopting a completely different writing style. And I will have to keep a wall up between styles and never 'slip'.
I've always had really poor luck in dating other girls who were in a technical field of some kind. I think it requires people with different kinds of minds to make a good relationship.
So you talked shit and challenged a cop in front of other cops? What the fuck do you expect to happen? That the cop will give you donuts and a get out of jail card? Not saying what happened to you was right, or legal, but if you are stupid enough to talk smack to cops when they are surrounded by other cops, you likely are going to get a bit of a beat down. Change cops to jock, druggy, drunk, etc and you'll get the same result.
Ahh, so you're putting cops in the same category as jocks, druggies and drunks? That makes me feel so much happier about them.
I've been watching and trying right along. The last time I tried was with TC 3. I still couldn't make heads or tails of the partitioning GUI, and it still seemed like it was going to erase everything instead of installing into a new partition.
Admittedly, I've been trying this on a VM which I've used btrfs for everything. So it doesn't test LVM. Maybe that works now. Unfortunately, all the systems I use LVM for are (for me) mission critical. Though I don't suppose there's any harm in firing up the installer and trying.
This is impossible if you are an open, public project. We can hardly work on a Fedora release with a new installer UI in secret. If we don't make some kind of effort to put out controlled messaging about the new installer UI, the result won't be that no-one knows about it until we're ready, the result will be that instead of controlled, accurate information being released, random, often inaccurate information will show up. Probably as a result of Phoronix taking public mailing list threads wildly out of context.
For open, public projects you do not merge new features into the mainline until they are reasonably baked. Yeah, people will learn about them far in advance, and that's just great. But you don't announce that they will be part of a release until they're done.
That code should never have been merged. It was not done. You should've limped along with the old Anaconda for Fedora 18 (which I know would've been something of a blow since you'd been hoping to have it in 17 if I'm not mistaken) and not merged the new Anaconda in. This decision should've been made at the new feature freeze point. It was clear the feature wasn't done.
I know a little bit about how you feel. I made a conscious decision not to kill my stepfather when I was young for a variety of reasons. Juvenile detention and the overall health of my family being my primary considerations. I'm still convinced that decision was correct, even though he was a horrible parent for me (and I suspect for my half-sister as well).
But the other person who responded to this is right. You need to stop living in the past. Be straight about the abusive behavior with your spouse. If they're good for you, they will help you compensate for your tendency to pass the abuse on to your children.
I have a very different standard for 'production ready' for Fedora and RHEL because you're correct. But 'production ready' for Fedora does, at the very least, mean feature complete and minimally tested.
I don't blame the anaconda guys for finding out that the problem was harder than they thought. That happens.
Exactly! I really appreciate the work they're doing. But the people managing the release as a whole should've known better than to do it the way they did.
They should never have merged in the new Anaconda in the state its in. It is not production ready. It is basically impossible to create a new LV or btrfs subvolume and install into it. So you are left with installing into a real partition. And on most of my computers I'm using btrfs or LVM and I've given them the whole HD, so that's not really an option.
Additionally, the UI for selecting where to install into is so confusing that I cannot say with confidence that the install isn't going to wipe out any existing partitions.
The old UI was kind of fiddly, and perhaps it was a bit opaque to newer users since it required some detailed knowledge of what a partition was and how it relates to a physical hard-drive, and LVM volume group or a btrfs volume. But at least it worked and you could make it do what you wanted.
Perhaps this new UI will be a lot better in the end. All I know is that merging the work into mainline Anaconda at this stage of its development was a huge mistake. It means that it will be much harder to go back to the old one should the new UI not be ready in time, or prove to be not-constructible.
I consider it basic software engineer to never count on a given feature that isn't done (to the point of having had at least some testing) to be available on release. You don't let your salespeople sell it. And you don't announce it. This is something I've always had a lot of respect for Google for. They rarely announce things until they're actually done. Software engineering is too unpredictable to do it any other way.
They fell asleep and were groggy the next day from 1/4 of the milkshake. Suppose they'd drunk the whole thing. They might be dead by now. Sorry, but I can't side with the kids on this. While I doubt the juvenile justice system is going to do them much good, what they did is definitely outside the bounds of acceptable behavior and should be considered criminal.
If I were the parents, I'd wait until they were convicted, then discuss sentencing options and see about making sure the harm is minimized. They deserve a really good scare and to see just how coldly the system can treat them for their incredibly outrageous and entitled behavior.
Slashdot Mirror
And you demonstrate his point perfectly. How many people know that collecting stray bird feathers lying on the ground might get them jail time? Is that an intended consequence of the law? It sounds like you know that regulation better than anybody and don't even care about any wider implications that will have surprising and awful effects, just like the bureaucrat guy in the comic.
As for the turtle example, the comic author explicitly gives the common snapping turtle as an example. A non-endangered species. State X passes a law about the snapping turtle at time T. And time T + 10 he does a vendor audit and after a lot of effort realizes that one of his vendors is now in a jurisdiction in which its illegal for them to sell him common snapping turtles. Unfortunately, the feds noticed at time T + 1. Oops, he's guilty and intent has nothing to do with it because the law isn't written that way.
While I think this is a good idea, I think that it's really too superficial. It very narrowly addresses a very specific problem with the law.
There are two really great little tidbits I found online that talk about what the actual problems with the law are:
The first link is actually a really great series that provides a very nice explanation for a lot of things about how criminal law works.
I wish Google had a nice capability system that would allow you to give a revocable authorization to the app so it didn't have to know your password. They do for some things, but I don't think they do for Google Drive specifically.
They all have undiscovered holes. What makes Java any riskier than IE? What makes it any riskier than Chrome or Firefox? Is it the lack of any update strategy on Oracle's part?
Tahoe sort of achieves this in an odd way. Directories contain hashes of the file they reference instead of an inode number. This means that a Tahoe node often doesn't even know who a file really belongs to, even though it knows its length.
The main issue with block storage is this...
Suppose you modify a data section of a file in a btrfs filesystem mounted on some kind of weird encrypted block device. There will be a whole tree of blocks that get modified, all the way up to the root node. All of these blocks have to be written before the root block is, and for a small file there will be several more blocks that need updating than there are data blocks on the file.
These two issues create a big synchronization problem and a lot of extra traffic.
In contrast, a good distributed filesystem protocol that's aware of individual files can send a single message that contains some kind of identifier for the file, and the new data it should contain. This message will often be smaller than a single filesystem block, and it will also usually be compressed before it gets on the wire. Much more efficient and while there are synchronization issues between updates to individual files, within a file there aren't any.
Oh, yeah. *sheepish grin* Of course, most popular existing cloud services do not support LAFS out of the box. :-/ So yeah, you'll have to layer it on something in the manner suggested above.
BTW, doing this at a block device level is likely a very poor idea. Block devices are very difficult to get right in a distributed fashion from a synchronization standpoint. They also are likely to cause a lot of excess network traffic since the units the system deals with are poorly matched to the logical units that are actually modified. A good distributed solution to this problem will at have to know something about the fact that you have individual files to be at all reasonable to use.
The first, and most interesting, is Tahoe LAFS. It does come with a FUSE driver, so it can be mounted like a regular filesystem. It is cloud-based and redundant to a degree you choose yourself. All copies stored are encrypted, so the only person who can read them is you. I'm not sure though if fetching from more nodes than you strictly need to reconstruct your original file actually buys you anything with that system, but I think it does.
You could also use something like a mountable version of Google Drive and then layer fuse-encfs on top of it. That's not quite as secure as encrypting at the block layer. The overall shape of your directory hierarchy is available, even if the individual file names and their contents are obscured. That should probably be good enough for most purposes.
Yes, you're right. I was probably one of only 2-5 people who would've written such a letter who worked in that office. So yeah, that probably helped at least as much as style.
If you're trying to avoid having two different identities associated when you're having an IRC conversation or something, that could get really tricky.
I've thought about that. That's an interesting and tricky problem. Though, if there's a program that can detect it, that means the patterns are codified well enough that you can write a program to obscure them. The problem is, what about the program that detects these patterns that you don't know the implementation of? Will you actually be fooling it?
Of course, you have the same problem if you adopt a different writing style. Is it different enough? Is something essential slipping through?
You could use both techniques. Have a program assist you in avoiding the use of certain words when using one voice and the use of others when using a different voice.
I worked for a smallish (but not incredibly tiny, maybe 100 employees) company and wrote a letter to the CEO once. We'd been castigated by someone who'd taken over the local office because the company was doing poorly. A number of austerity measures were implemented. I did not find those to be that annoying because I realized it was either that or not have a job. But the castigation didn't sit well with me. We were in trouble because of the decisions of a few bad managers, not the behavior of average employees.
So I wrote a letter about it. He stripped my name off and presented it in an executive meeting to all the people directly under him. He asked "Why am I getting letters like this?". Everybody who worked in my office immediately knew who it was. I had a distinctive writing voice, and a strong reputation.
It did not lead to me being fired. I was actually highly respected there. It led to me being encouraged to have an honest sit-down talk with the new manager for our division (the guy who'd made the speech I wasn't happy about). I think we both came away from that meeting a lot happier about the other.
But that was a strong lesson to me. If I ever really want to be anonymous I'm going to have to purposely work on adopting a completely different writing style. And I will have to keep a wall up between styles and never 'slip'.
I've always had really poor luck in dating other girls who were in a technical field of some kind. I think it requires people with different kinds of minds to make a good relationship.
When are you sending a drone to attack me?
So you talked shit and challenged a cop in front of other cops? What the fuck do you expect to happen? That the cop will give you donuts and a get out of jail card? Not saying what happened to you was right, or legal, but if you are stupid enough to talk smack to cops when they are surrounded by other cops, you likely are going to get a bit of a beat down. Change cops to jock, druggy, drunk, etc and you'll get the same result.
Ahh, so you're putting cops in the same category as jocks, druggies and drunks? That makes me feel so much happier about them.
I would like to extend the mandate for drone killings to people who decide that people should be killed because they're irritating.
Bug 860677
I've been watching and trying right along. The last time I tried was with TC 3. I still couldn't make heads or tails of the partitioning GUI, and it still seemed like it was going to erase everything instead of installing into a new partition.
Admittedly, I've been trying this on a VM which I've used btrfs for everything. So it doesn't test LVM. Maybe that works now. Unfortunately, all the systems I use LVM for are (for me) mission critical. Though I don't suppose there's any harm in firing up the installer and trying.
This is impossible if you are an open, public project. We can hardly work on a Fedora release with a new installer UI in secret. If we don't make some kind of effort to put out controlled messaging about the new installer UI, the result won't be that no-one knows about it until we're ready, the result will be that instead of controlled, accurate information being released, random, often inaccurate information will show up. Probably as a result of Phoronix taking public mailing list threads wildly out of context.
For open, public projects you do not merge new features into the mainline until they are reasonably baked. Yeah, people will learn about them far in advance, and that's just great. But you don't announce that they will be part of a release until they're done.
That code should never have been merged. It was not done. You should've limped along with the old Anaconda for Fedora 18 (which I know would've been something of a blow since you'd been hoping to have it in 17 if I'm not mistaken) and not merged the new Anaconda in. This decision should've been made at the new feature freeze point. It was clear the feature wasn't done.
I know a little bit about how you feel. I made a conscious decision not to kill my stepfather when I was young for a variety of reasons. Juvenile detention and the overall health of my family being my primary considerations. I'm still convinced that decision was correct, even though he was a horrible parent for me (and I suspect for my half-sister as well).
But the other person who responded to this is right. You need to stop living in the past. Be straight about the abusive behavior with your spouse. If they're good for you, they will help you compensate for your tendency to pass the abuse on to your children.
I have a very different standard for 'production ready' for Fedora and RHEL because you're correct. But 'production ready' for Fedora does, at the very least, mean feature complete and minimally tested.
I don't blame the anaconda guys for finding out that the problem was harder than they thought. That happens.
Exactly! I really appreciate the work they're doing. But the people managing the release as a whole should've known better than to do it the way they did.
They should never have merged in the new Anaconda in the state its in. It is not production ready. It is basically impossible to create a new LV or btrfs subvolume and install into it. So you are left with installing into a real partition. And on most of my computers I'm using btrfs or LVM and I've given them the whole HD, so that's not really an option.
Additionally, the UI for selecting where to install into is so confusing that I cannot say with confidence that the install isn't going to wipe out any existing partitions.
The old UI was kind of fiddly, and perhaps it was a bit opaque to newer users since it required some detailed knowledge of what a partition was and how it relates to a physical hard-drive, and LVM volume group or a btrfs volume. But at least it worked and you could make it do what you wanted.
Perhaps this new UI will be a lot better in the end. All I know is that merging the work into mainline Anaconda at this stage of its development was a huge mistake. It means that it will be much harder to go back to the old one should the new UI not be ready in time, or prove to be not-constructible.
I consider it basic software engineer to never count on a given feature that isn't done (to the point of having had at least some testing) to be available on release. You don't let your salespeople sell it. And you don't announce it. This is something I've always had a lot of respect for Google for. They rarely announce things until they're actually done. Software engineering is too unpredictable to do it any other way.
Thank you for the link though. :-)
After dying for the 5th or 6th time shortly after leaving the station, I think perhaps I will give it a miss.
They fell asleep and were groggy the next day from 1/4 of the milkshake. Suppose they'd drunk the whole thing. They might be dead by now. Sorry, but I can't side with the kids on this. While I doubt the juvenile justice system is going to do them much good, what they did is definitely outside the bounds of acceptable behavior and should be considered criminal.
If I were the parents, I'd wait until they were convicted, then discuss sentencing options and see about making sure the harm is minimized. They deserve a really good scare and to see just how coldly the system can treat them for their incredibly outrageous and entitled behavior.