I don't discount your experience, but I wanted to add some sunshine in there, that maybe it's not universally dreary out there.
First, I'll say I have a pretty high tolerance for other people. As far as I'm concerned, you live in the world, meaning you live in a community of people, and you don't have the right for your "personal space" (whether it be physical, visual, aural or olfactory) to be free of the experience of other people.
I have asked on two occasions that someone stop kicking my seat, in a movie theater. One time, the recipiente was pretty shocked at me and obviously upset, but they stopped kicking my seat; in the other case, they apologized.
I'm no frequent flyer, but in the last couple of years I've flown to several destinations, including trips to Europe and cross-country trips (and I absolutely hate flying, I'm the worst white-knuckle flyer). I had two times where someone else made the trip unpleasant for me: once, when a kid was talking about how we were going to crash, but really, that's just my own foible; and another time, when someone started getting airsick behind me when we were at the gate. Which is hardly his fault. Pretty much everyone on both my flights was polite and, if not friendly, at least kept to themselves.
Yeah, that mini-flyer (using capacitors or whatever, I guess, as power) was what I had in mind when I heard this. I'm not sure your experience or mine as an RC flyer is directly applicable, though, any more than flying a Predator is like flying hobbyist RC craft. Computers can fly things people can't, like the X-29, that no human can keep stable. With the right kind of sensing (maybe even external to the flyer) I could see computer control keeping it stable. The flyer itself shows that if you keep something light and flimsy enough, you can fly it with electrical power for a few minutes. If you figure the "men in black" can do a little better job than the flyer you see here, it could carry a small still camera and a small transmitter or onboard memory.
Is this the case? I have no idea. But it's not laughable. Of course, an actual dragonfly is an entirely different thing. That might be laughable, or at least, much, much harder than a little helicopter.
Also, some people have said, "Oh, they wouldn't use it for this, because it would be stupid (one of the flyers would be caught, you can spy more effectively in other ways." In my experience you can never exclude any actions of the government because it would be "too stupid."
Even given all that, I don't see it. Mostly, because I don't really see any more reason this would be true--reports don't sound credible. This sounds like it comes from the same kind of people that believe in 9/11 conspiracies and chemtrails.
Jury Nulification is NOT for the win in RIAA cases
That makes sense to me. What if I, as a juror, feel that the plaintiff hasn't demonstrated damages, even if the law provides for some statutory fine? Aren't these two matters of law in conflict?
I suspect in at least some of these cases, the SAN is not continuous, and they're actually doing backups to the SAN. Part of the storage mentioned will be the online portion of a hierarchical storage manager or similar.
I suspect the OP is trying (pretty unsuccessfully) to communicate an argument about social import from these hazard statistics; which is of course not to the point of the article, no to your point at all.
I think the idea is that absolute risk is a measure of the magnitude of social ill, and therefore an index to how much effort "we" should make in ameliorating it. Not a lot of people die on planes, therefore we shouldn't spend nearly as much effort on making them safer. Or something. I dunno.
Almost everything looks obvious after the fact. The wheel is "obvious", yet very few cultures actually invented it.
The fact that Google is *still* the best search engine ought to tell you something about the difficulty.
I think Google's done a great job, but this is entirely the wrong impression. Search engines were not only obvious, they were old hat, the battles already fought and decided, when Google appeared on the scene. And Google has never, by any standard measure, been the best search engine, except for being fast. And it's not the best now, in fact it's worse than when it started.
Google's "breakthrough" was being fast through distributed search, which is something that all the search engines were working on for some time. Google won this by being latecomers to the search game, that is, not having any customers to lose by risking a different back-end architecture; and by being fortunate that the big Internet portals at the time made poor decisions (Yahoo thought directories were better and never committed to search, Excite was consumed by the monumentally misguided @Home). There's no sense in which their founders were smarter or worked harder than the founders of any other technology company at the time.
Now, lots of those founders are or were doing "just fine"--a lot better than me. Hard, smart work definitely counts for something. But the difference between "quite successful" and "super-rich" is luck, not hard work. The google founders weren't smarter or harder-working than a hundred other people. I know a very successful and famous Internet celebrity and multimillionaire, who, quite frankly, isn't smarter than anybody.
The question is, who cares about your software? You're trying to enter a space with well-established mature standard solutions already in place. I can't run your thing on free platforms, any form of software-enforced licensing invites downtime for no legitimate reason, and if I wanted those restrictions I'd already be using MS Project and Outlook.
The idea that your software would somehow be so in-demand that people would be copying it everywhere is a fantasy. You should love to have that "problem." The problem you'll face in entering a market is that no one will want to use your software, licensing or no. You're discovering that there are no good options for being in the business of selling retail desktop software--essentially, either you are Microsoft, or this is a bad business to be in. You need to be in a somewhat different business (perhaps involving this software you're talking about); this isn't really a question of what licensing restrictions are appropriate.
If you're going to go the proprietary software route, follow the model of Oracle and allow administrators at your customer companies to set the license restrictions in accordance with whatever they bought from you. Write your license to reserve the right to audit for compliance, but the software itself should do nothing. No license keys, no phoning home, no downtime because of your artificial decreases in the quality of your product. You should be doing nothing to discourage adoption of your software within a company or without.
It's true that not having these restrictions may mean you get paid less. If you put a bunch of restrictions in, you're making it more likely you won't get paid at all.
Perhaps both sets of patents could be invalidated, then. I suspect very much that somewhere someone developed a database technology with copy-on-write with an advancing root block; I don't, however, have actual knowledge of that. It's just based on the pattern of database technology trickling down to filesystems and memory storage.
Re:Our credulity is not surprising...
on
Why Myths Persist
·
· Score: 1
Do you actually telecommute full time? Or are you blowing it out your hole because you like to type?
Telecommuting full time isn't like staying home a day or two a week. It's much more disconnected. We're not talking about the social aspects of working (although that's part of it--part of what you do at work is reinforce your opinions of those you work with, and read their opinions of you. It's too bad you've missed this--but it doesn't surprise me, you don't exactly sound like a 'thinker'); we're talking about what physical presence brings into it. You'd have to be supremely inobservant not to understand that people get each other's attention physically, that physical presence is the nexus of a great deal of getting things done in an office, and that being physically disconnected is really distancing from what's going on there.
Video conferencing, shared terminal sessions, conference calls (ugh), phone, IM, email are all really poor at enabling actual work to get done (in my experience, the best is email and some kind of shared authoring system; while no one ever actually gets things done on conference calls and video conferences). Is a robot perfect? No. And sometimes physical distance can be a benefit as well as a hindrance, if you play it right. But if you think that planning and setting up video conferences with a telecommuter is the same thing as asynchronously getting individual's attention via physical presence, well... then you haven't thought much, have you?
I have an enormous desire to see a comic book cover of Superman giving a concert with his superguitar and taunting us all with how we can't hear his beautiful music, like the dick he is.
True (sort of), but that's a specific weakness for a non-specific application description. It's true that for a lot of people, all data looks like strings that you parse, extract, and throw regexes at until you're blue in the face, but as a general programming approach that's more an artifact of Perl and shell scripting habits than anything else. I would like to see a standard and high-performance bstring implementation, though (and yes, I did start writing my own unicode/bstring thing:) ). Here's another place where a larger community could help.
C calling is a matter of taste, I guess. I didn't find doing it from Erlang any more difficult or complicated than writing XS modules or any similar tasks. The model of a port driver is much safer and has a lot to recommend it over being forced to link in external libraries (though you can do that in Erlang, too, if you really want).
There are definitely powerful pieces of Erlang that are insufficiently documented, I hope this increasingly becomes the focus of the community (documentation and how-tos). IIRC I did see a good
how-to on writing C drivers.
Since we're criticizing, one valid criticism I've heard is that Erlang's metaprogramming system is clunky (which it is). I think someone was working on a general macro facility for Erlang, though.
Even so, when the state drunk drivers attend AA, they don't force them to go to a gay and lesbian AA clubhouse. That is a better analogy.
Actually, that's often exactly what they do (never mind the gay/lesbian specific), it's not like you get to pick any alcohol or drug treatment program you like--there's a limited list of diversions. Now, usually you agree to a diversion to avoid a sentence like a fine or jail term; but try, for example, to find a non-smoking AA group (if that's important to you). I'd say your analogy is apt but rather undermines your point.
Sort of, but this is a naïve understanding. State is required or you're not doing anything interesting. You're just pushing it around. If you're the guy in charge of the web servers, it might seem like having sessions on the app server and plugin based request routing is a good idea, but it just pushes the problem to the app server guy. If you're the app server guy, it might seem like a good idea to put sessions in a database but that just pushes the state there. You're not solving any fundamental problems, just playing checkers with it. And replicating session information is a losing proposition for scaling because as the number of multimaster nodes grows so does its overhead. Loosely-coupled multiple master replication like that is very hard to get right.
Sometimes you can get away with keeping state with the client, sometimes this isn't desirable. It depends what you're doing but it's not a general solution.
The general solution to horizontal scalability is horizontal partitioning. This works for the stateful tiers as well. But integrating this with high availability is either complicated or inefficient (you get to pick).
Luckily, we now have a good Erlang book in print (again): Programming Erlang by Joe Armstrong. Learn it, live it, love it.
The language is almost certainly not suited to the kind of task described (it might be, but it's unlikely)
I disagree. Erlang is perfectly good for general programming tasks and particularly well-suited for the sorts of demands placed on public web applications (which is sort of the undercurrent of the requester's question, I think). And while it's true that messaging, lightweight parallelism, supervision trees, exit trapping and so forth are principles that might could be applied to other programming languages: the question would be, "why?" It's so much easier in Erlang. And Erlang isn't just a programming language, it's also a technology for building concurrent distributed non-stop systems. It's "batteries included" and comes with lots of useful libraries, including a web development kit and so forth. It is also easy to integrate with external libraries (indeed, this was Erlang's primary problem domain as it was developed) such as those for Java and C, and unlike other languages does so in a safe way (where a crash in the library won't crash the program).
With current technological advances being exponential...
What does this mean, exactly? In year 0 we had a technology of 1, in 100 a technology of 2, 4 in 200, and so on until in 2000 we reached a technology of 1048576 (that's over a million times more technological!)?
I agree with you wholeheartedly on the likelihood that humanity will bring about its own end.
Re:Geeks do- everyone else doesn't.
on
The DRM Scorecard
·
· Score: 1
It depends on your definition of "hurt." The music industry considers it a "harm" when you don't pay iTunes your $1 for a song you already have on CD. They want you to pay again and again for music you already own. To them, any time they can't squeeze the maximum possible profit out of something, it's a "loss."
The people who say DRM is not meant to be unbreakable, it's meant to deter to "casual copying," have it almost right. It's meant to prevent legitimate owners from legally reusing material they already own. DVD CSS and its sequelae are precisely meant to prevent you from making a backup of your DVD, or of saving it to hard drive or memory stick to watch later. Because they want to charge you for the second disc. Because they want to charge you for watching the movie on your computer. And then again on your PSP. And then again on your phone. And then again when you watch it again.
DRM has nothing to do with piracy, and everything to do with controlling the behavior of legal users.
Proper permissions are not sufficient protection; as you can imagine, file and dir protections are often incorrectly set, improperly changed, or maliciously changed, by sysadmins or others. And permissions apply to passive objects (files), not active ones like executables, which is (partly) why qmail also exploits multiple user IDs (UIDs) as well as group ID (GIDs) in Unix to achieve protection between components.
Yes. There's a whole discipline of structure and code that must be applied when reading a run-time configuration in a privileged program: for the dual purpose of ensuring that the configuration is "proper", that is, could never have been changed by an attacker, as well as to make sure that the privileges are not being used to read something that isn't supposed to be read. In its most basic rendition the file and directory permissions from the root down to the file need to be examined and compared to a (hardcoded!) standard to make sure they are correct. And even that's not right, because there's no way in most systems to ensure there isn't a race between the various checks and the reading of the file; and there's no way to make it portable, because filesystem permissions and semantics vary from system to system and filesystem type to filesystem type (consider, for example, what AFS does with Unix permissions).
So you have all this code and structure (all inapposite to the task being addressed by the program--that is, unnecessary) which is unlikely to ever be well-tested, and can't even be correct. For what? To turn a compile-time parameter into a run-time parameter? Sometimes that's the right call, but not always.
I wasn't aware it was "under control". Nearly all of what I receive in the mail (and I wager this is true for most people) would be what I would classify as spam if I received it in email.
Slashdot Mirror
I don't discount your experience, but I wanted to add some sunshine in there, that maybe it's not universally dreary out there.
First, I'll say I have a pretty high tolerance for other people. As far as I'm concerned, you live in the world, meaning you live in a community of people, and you don't have the right for your "personal space" (whether it be physical, visual, aural or olfactory) to be free of the experience of other people.
I have asked on two occasions that someone stop kicking my seat, in a movie theater. One time, the recipiente was pretty shocked at me and obviously upset, but they stopped kicking my seat; in the other case, they apologized.
I'm no frequent flyer, but in the last couple of years I've flown to several destinations, including trips to Europe and cross-country trips (and I absolutely hate flying, I'm the worst white-knuckle flyer). I had two times where someone else made the trip unpleasant for me: once, when a kid was talking about how we were going to crash, but really, that's just my own foible; and another time, when someone started getting airsick behind me when we were at the gate. Which is hardly his fault. Pretty much everyone on both my flights was polite and, if not friendly, at least kept to themselves.
Yeah, that mini-flyer (using capacitors or whatever, I guess, as power) was what I had in mind when I heard this. I'm not sure your experience or mine as an RC flyer is directly applicable, though, any more than flying a Predator is like flying hobbyist RC craft. Computers can fly things people can't, like the X-29, that no human can keep stable. With the right kind of sensing (maybe even external to the flyer) I could see computer control keeping it stable. The flyer itself shows that if you keep something light and flimsy enough, you can fly it with electrical power for a few minutes. If you figure the "men in black" can do a little better job than the flyer you see here, it could carry a small still camera and a small transmitter or onboard memory.
Is this the case? I have no idea. But it's not laughable. Of course, an actual dragonfly is an entirely different thing. That might be laughable, or at least, much, much harder than a little helicopter.
Also, some people have said, "Oh, they wouldn't use it for this, because it would be stupid (one of the flyers would be caught, you can spy more effectively in other ways." In my experience you can never exclude any actions of the government because it would be "too stupid."
Even given all that, I don't see it. Mostly, because I don't really see any more reason this would be true--reports don't sound credible. This sounds like it comes from the same kind of people that believe in 9/11 conspiracies and chemtrails.
We've been preponing meetings this way since long back.
That makes sense to me. What if I, as a juror, feel that the plaintiff hasn't demonstrated damages, even if the law provides for some statutory fine? Aren't these two matters of law in conflict?
I suspect in at least some of these cases, the SAN is not continuous, and they're actually doing backups to the SAN. Part of the storage mentioned will be the online portion of a hierarchical storage manager or similar.
I suspect the OP is trying (pretty unsuccessfully) to communicate an argument about social import from these hazard statistics; which is of course not to the point of the article, no to your point at all.
I think the idea is that absolute risk is a measure of the magnitude of social ill, and therefore an index to how much effort "we" should make in ameliorating it. Not a lot of people die on planes, therefore we shouldn't spend nearly as much effort on making them safer. Or something. I dunno.
Zelda/Nintendo people, Apple fanboys, Pythonistas and Emacsers are all like that. If you don't like it, there's something wrong with you.
More important, what are the factors for 15? I got as far as 1, and 3 is looking decent, but I'm stuck.
I think Google's done a great job, but this is entirely the wrong impression. Search engines were not only obvious, they were old hat, the battles already fought and decided, when Google appeared on the scene. And Google has never, by any standard measure, been the best search engine, except for being fast. And it's not the best now, in fact it's worse than when it started.
Google's "breakthrough" was being fast through distributed search, which is something that all the search engines were working on for some time. Google won this by being latecomers to the search game, that is, not having any customers to lose by risking a different back-end architecture; and by being fortunate that the big Internet portals at the time made poor decisions (Yahoo thought directories were better and never committed to search, Excite was consumed by the monumentally misguided @Home). There's no sense in which their founders were smarter or worked harder than the founders of any other technology company at the time.
Now, lots of those founders are or were doing "just fine"--a lot better than me. Hard, smart work definitely counts for something. But the difference between "quite successful" and "super-rich" is luck, not hard work. The google founders weren't smarter or harder-working than a hundred other people. I know a very successful and famous Internet celebrity and multimillionaire, who, quite frankly, isn't smarter than anybody.
The question is, who cares about your software? You're trying to enter a space with well-established mature standard solutions already in place. I can't run your thing on free platforms, any form of software-enforced licensing invites downtime for no legitimate reason, and if I wanted those restrictions I'd already be using MS Project and Outlook.
The idea that your software would somehow be so in-demand that people would be copying it everywhere is a fantasy. You should love to have that "problem." The problem you'll face in entering a market is that no one will want to use your software, licensing or no. You're discovering that there are no good options for being in the business of selling retail desktop software--essentially, either you are Microsoft, or this is a bad business to be in. You need to be in a somewhat different business (perhaps involving this software you're talking about); this isn't really a question of what licensing restrictions are appropriate.
If you're going to go the proprietary software route, follow the model of Oracle and allow administrators at your customer companies to set the license restrictions in accordance with whatever they bought from you. Write your license to reserve the right to audit for compliance, but the software itself should do nothing. No license keys, no phoning home, no downtime because of your artificial decreases in the quality of your product. You should be doing nothing to discourage adoption of your software within a company or without.
It's true that not having these restrictions may mean you get paid less. If you put a bunch of restrictions in, you're making it more likely you won't get paid at all.
Thank you for mentioning Master and Commander: The Far Side of the World and I'll raise you Jaws.
Perhaps both sets of patents could be invalidated, then. I suspect very much that somewhere someone developed a database technology with copy-on-write with an advancing root block; I don't, however, have actual knowledge of that. It's just based on the pattern of database technology trickling down to filesystems and memory storage.
Very nicely played, sir.
Do you actually telecommute full time? Or are you blowing it out your hole because you like to type?
Telecommuting full time isn't like staying home a day or two a week. It's much more disconnected. We're not talking about the social aspects of working (although that's part of it--part of what you do at work is reinforce your opinions of those you work with, and read their opinions of you. It's too bad you've missed this--but it doesn't surprise me, you don't exactly sound like a 'thinker'); we're talking about what physical presence brings into it. You'd have to be supremely inobservant not to understand that people get each other's attention physically, that physical presence is the nexus of a great deal of getting things done in an office, and that being physically disconnected is really distancing from what's going on there.
Video conferencing, shared terminal sessions, conference calls (ugh), phone, IM, email are all really poor at enabling actual work to get done (in my experience, the best is email and some kind of shared authoring system; while no one ever actually gets things done on conference calls and video conferences). Is a robot perfect? No. And sometimes physical distance can be a benefit as well as a hindrance, if you play it right. But if you think that planning and setting up video conferences with a telecommuter is the same thing as asynchronously getting individual's attention via physical presence, well... then you haven't thought much, have you?
I have an enormous desire to see a comic book cover of Superman giving a concert with his superguitar and taunting us all with how we can't hear his beautiful music, like the dick he is.
True (sort of), but that's a specific weakness for a non-specific application description. It's true that for a lot of people, all data looks like strings that you parse, extract, and throw regexes at until you're blue in the face, but as a general programming approach that's more an artifact of Perl and shell scripting habits than anything else. I would like to see a standard and high-performance bstring implementation, though (and yes, I did start writing my own unicode/bstring thing :) ). Here's another place where a larger community could help.
C calling is a matter of taste, I guess. I didn't find doing it from Erlang any more difficult or complicated than writing XS modules or any similar tasks. The model of a port driver is much safer and has a lot to recommend it over being forced to link in external libraries (though you can do that in Erlang, too, if you really want).
There are definitely powerful pieces of Erlang that are insufficiently documented, I hope this increasingly becomes the focus of the community (documentation and how-tos). IIRC I did see a good how-to on writing C drivers.
Since we're criticizing, one valid criticism I've heard is that Erlang's metaprogramming system is clunky (which it is). I think someone was working on a general macro facility for Erlang, though.
Oh, the entire argument was that he might be exposed to gays or lesbians? In that case, we're safe, since Windows is neither gay nor lesbian.
Actually, that's often exactly what they do (never mind the gay/lesbian specific), it's not like you get to pick any alcohol or drug treatment program you like--there's a limited list of diversions. Now, usually you agree to a diversion to avoid a sentence like a fine or jail term; but try, for example, to find a non-smoking AA group (if that's important to you). I'd say your analogy is apt but rather undermines your point.
Sort of, but this is a naïve understanding. State is required or you're not doing anything interesting. You're just pushing it around. If you're the guy in charge of the web servers, it might seem like having sessions on the app server and plugin based request routing is a good idea, but it just pushes the problem to the app server guy. If you're the app server guy, it might seem like a good idea to put sessions in a database but that just pushes the state there. You're not solving any fundamental problems, just playing checkers with it. And replicating session information is a losing proposition for scaling because as the number of multimaster nodes grows so does its overhead. Loosely-coupled multiple master replication like that is very hard to get right.
Sometimes you can get away with keeping state with the client, sometimes this isn't desirable. It depends what you're doing but it's not a general solution.
The general solution to horizontal scalability is horizontal partitioning. This works for the stateful tiers as well. But integrating this with high availability is either complicated or inefficient (you get to pick).
Luckily, we now have a good Erlang book in print (again): Programming Erlang by Joe Armstrong. Learn it, live it, love it.
I disagree. Erlang is perfectly good for general programming tasks and particularly well-suited for the sorts of demands placed on public web applications (which is sort of the undercurrent of the requester's question, I think). And while it's true that messaging, lightweight parallelism, supervision trees, exit trapping and so forth are principles that might could be applied to other programming languages: the question would be, "why?" It's so much easier in Erlang. And Erlang isn't just a programming language, it's also a technology for building concurrent distributed non-stop systems. It's "batteries included" and comes with lots of useful libraries, including a web development kit and so forth. It is also easy to integrate with external libraries (indeed, this was Erlang's primary problem domain as it was developed) such as those for Java and C, and unlike other languages does so in a safe way (where a crash in the library won't crash the program).
Apparently this isn't like playing DVDs on the PS2 was, and the Blu-Ray player and software in the PS3 is excellent, and well-regarded.
What does this mean, exactly? In year 0 we had a technology of 1, in 100 a technology of 2, 4 in 200, and so on until in 2000 we reached a technology of 1048576 (that's over a million times more technological!)?
I agree with you wholeheartedly on the likelihood that humanity will bring about its own end.
It depends on your definition of "hurt." The music industry considers it a "harm" when you don't pay iTunes your $1 for a song you already have on CD. They want you to pay again and again for music you already own. To them, any time they can't squeeze the maximum possible profit out of something, it's a "loss."
The people who say DRM is not meant to be unbreakable, it's meant to deter to "casual copying," have it almost right. It's meant to prevent legitimate owners from legally reusing material they already own. DVD CSS and its sequelae are precisely meant to prevent you from making a backup of your DVD, or of saving it to hard drive or memory stick to watch later. Because they want to charge you for the second disc. Because they want to charge you for watching the movie on your computer. And then again on your PSP. And then again on your phone. And then again when you watch it again.
DRM has nothing to do with piracy, and everything to do with controlling the behavior of legal users.
Yes. There's a whole discipline of structure and code that must be applied when reading a run-time configuration in a privileged program: for the dual purpose of ensuring that the configuration is "proper", that is, could never have been changed by an attacker, as well as to make sure that the privileges are not being used to read something that isn't supposed to be read. In its most basic rendition the file and directory permissions from the root down to the file need to be examined and compared to a (hardcoded!) standard to make sure they are correct. And even that's not right, because there's no way in most systems to ensure there isn't a race between the various checks and the reading of the file; and there's no way to make it portable, because filesystem permissions and semantics vary from system to system and filesystem type to filesystem type (consider, for example, what AFS does with Unix permissions).
So you have all this code and structure (all inapposite to the task being addressed by the program--that is, unnecessary) which is unlikely to ever be well-tested, and can't even be correct. For what? To turn a compile-time parameter into a run-time parameter? Sometimes that's the right call, but not always.
I wasn't aware it was "under control". Nearly all of what I receive in the mail (and I wager this is true for most people) would be what I would classify as spam if I received it in email.