People have done research into this - these devices are just about as dangerous as being legally drunk.
I, for one, am automatically suspicious of arguments that begin with "people have done research." Who are these anonymous people? Where was the research published? Has it been repeated? You're appealing to a nonsense authority.
With a law like this, there are no ifs, ands, or buts. No defense. You're caught, you pay. No "but really, Sir Judge, I'm not actually a reckless driver when I text".
Are you saying that someone shouldn't be able to present an argument? The point of a common law system like ours is the ability to adapt the law to the facts of a particular case. By passing laws like this, we simply limit the judge's ability to do his job. As a result, we'll have coarser justice. If a judge is letting people off for texting while driving and the people really disagree with that, then that judge will be replaced. And who knows? Someone might indeed deserve to be cleared of the charge.
4. It's about damn time we started seeing laws like this. Of course we shouldn't need them, but in my experience 90% of the bad drivers on the road are either yakking on their phone, or texting, or in some cases both. Seriously, how hard is it to just (GASP!) go without talking to your sister for a few minutes? We invented voicemail for a reason!
And I bet 90% of the bad drivers you see are listening to music. Let's ban that in cars too. The fact is that when you notice that somebody is driving badly, you tend to look for someone to blame that driving on.
For example,
"Oh, he's driving like that because his car has rust spots and doesn't care about it."
"Oh, he's driving like that because he's black."
"Oh, she's driving like that because she's a woman. Them women can't drive."
But you don't notice all the poor, black, or female people who are in fact excellent drivers. The same idea applies to cell phones. Most people can drive well and use cell phones responsibly. You just don't notice these people.
Furthermore, it won't change the fact that society as a whole accepts the practice, and that the law is the work of a vocal minority. I live in New York, and we've banned cell phone conversations in cars for some time now. Yet people think of it as wrong in the same sense that driving five miles per hour over the speed limit is wrong -- that is, not morally wrong at all.
Contrast that with how people feel about drunk driving -- if you tell friends you drive drunk, they'll give you the look they'd give you if you told them you killed kittens as a hobby. The difference is that drunk driving is a real danger.
*sigh* In more general terms, the law should reflect the morality of society as a whole. When someone not wrong is made illegal, the credibility of the law is diminished. People lose respect for all laws, not just the ridiculous one. They become cynical; participation in government drops as people feel that they can't affect their own government. The government abuses that cynical indifference to grab even more power, and the cycle repeats and repeats until we live in an authoritarian police state. It's happened before and it's happening again.
If these kinds of driving things really are wrong enough to warrant laws of their own, then the public needs to be educated FIRST. If they don't clamor all over their legislators to pass the law on their own, then perhaps the law isn't needed in the first place.
Arthur C Clark addressed this issue in Songs of Distant Earth, actually. I was impressed. His solution? Put a big chunk of ice in front of the spacecraft and let it ablate away as the craft encounters bits of space debris; in fact, the plot involves the need to obtain another ice shield.
And who do you make license the patent? Everyone who downloads the source tarball? Licensing requires distribution restrictions, and that's antithetical to the whole idea of open source software. It can't work.
Not everything in poor taste ought to be illegal; that you can't think of something you'd be prosecuted under probably means that you couldn't be prosecuted for anything -- shunned, maybe, or rebuked. I don't think there's anything illegal about that statement. If we try to outlaw people becoming offended, then we'll have to also outlaw the kind of free expression that let us develop into what we are today.
Virtual desktops have several advantages compared to real ones:
Switching latency: it's much slower to mash the keyboard to switch desktops than to move one's eye.
Simultaneous typing: you can't enter text in one window on a virtual desktop while simultaneously viewing a window on a different virtual desktop; I do this all the time on my dual-monitor setup when looking at API documentation.
Spanning: although it's ugly, spanning windows across both heads comes in handy more often than you'd think, especially for badly-written pages or images with strange aspect ratios.
More space for monitors: with more _real_ desktop space, you have more space to put various useful sticky windows. For example, I have gkrellm instances monitoring our servers sticky on my left monitor; with a single-head setup, I'd have to leave the monitors on just one of the desktops, which would defeat the point of constant monitoring.
The phrase you want to use is "raises the question," not "begs the question." The latter refers very specifically to circular reasoning, which isn't what you meant to describe.
That's going to fail miserably for AOL users at least --- the same user session can result in requests from many different proxies, each with a different IP address.
Also, the "PHP session ID" _is_ stored in a cookie. How else would it work?
I keep seeing this point labored again and again, yet it's simply not true. The assumption of having only 80 years of uranium only applies if 1) you consider only the reserves available at current market prices, a minuscule fraction of the world's total known reserves, and 2) don't consider the use of breeder reactors, which process fuel ~100 times more efficiently than conventional light water reactors do.
Plus, there's thorium, which is three times as common as uranium and also fissile.
Such functionality would probably be beyond the basic options of installing an unpackaged app from source code. But there's no reason that additional information couldn't be included with packaged apps detailing the more common options.
At least in the RPM-speaking world, we already have this functionality in the SRPM, though not in a formalized sense. Often, compile-time options require only very small changes to the spec, or can be given on the command line. For example, the bytecode compiler option for most freetype RPM packages falls into this category.
The fewer apps you're running, the fewer avenues of attack there are for you to be compromised. This could be a great feature for securing boxes.
I believe that the set of people who want to go gung-ho securing their boxes, who know what they're doing, AND who can't be bothered to recompile packages from SRPM form is very small.
Or you can simply not handle the recompilation bit at all and eliminate all the needless complexity you've described involving handling changed dependencies.
Going with your lDAP example, just always install the LDAP libraries. What's the harm? A few kilobytes of disk space in exchange for a much-simplified package system is a perfectly acceptable tradeoff. If by installing LDAP you eliminate a huge headache involving recompiling half the distribution, you win --- and it's not as if this LDAP functionality is actually used unless specifically enabled, and as an admin, I save time.
To carry the example to a silly extreme, why not have the distribution check what libc functions each application used and recompile it dynamically? After all, why include fchdir(2) if nobody uses it?
For modules that can't be handled with the always-install approach, a plugin architecture is more appropriate, in which packages are detected and loaded at runtime, and specific small packages for each module exist. For example, Redhat-family distributions use this approach for cyrus-sasl authentication methods, and it works well.
There's no need to introduce the needless complexity and computational expense of automatic recompilation.
Don't you fucking see that it DOESN'T MATTER what's causing the climate change? The reality is now indisputable, and must be dealt with if we're to avoid massive human suffering regardless of whether the cause is natural or man-made. There are options that must be considered, and this pointless bickering is just getting in the way.
Red Hat has commercial interests, and the corporation goes out of its way to neuter the software that ships with its distribution. Stock xine, xmms, and so on are fully capable.
An open-source project would never deliberately restrict its feature set in order to appease some corporation; whatever is technologically possible gets implemented. Corporations trying to limit technologically-possible things by gentleman's agreement is figuratively putting a very small finger in a very large dike; eventually, the whole thing will come down.
Idiots at my school keep asking about Vista, and are eager to install it. Fools. Don't people know it's a bad idea to install any new piece of software right away?
In my "university"'s operating systems class, we didn't even write any kernel code or read any open operating system's source. All labs were accomplished by using ordinary processes to simulate parts of a generic operating system kernel, though in previous years, some custom hacked-together simulation was used instead. Then again, this place is so deeply steeped in Microsoft culture that the only real debates are over whether to use.NET or "Visual C++" to write new client software. It's no wonder that open-source code is such anathama here that no kernel code at all is seen as a better alternative.
This paper is absolutely ridiculous, and its author is scaremongering --- if you have access to a site's scripting system via some cross-site vulnerability, then you don't _need_ to subvert an object's prototype to change its behavior. If you're relying on client-side code of any sort, be it written in Javascript or C, for security, you're up a creek without a paddle anyway. Oh nooes, man in the middle proxy attacks! Oh noes, browser bugs allowing javascript to leak outside its security context! There is no security vulnerability in this paper that hasn't been known and worked around for years. I'm wondering what kind of agenda the author has in writing this, actually.
So what if you have to provide the source for InnoDB? There's a process boundary between InnoDB and the program that uses the database. Why would you have to provide the source for your program that only communicated with MySQL over IPC, even under the GPLv3?
Lisp is all that safe a language, and can be somewhat strange: I'm a little confused by the specification's discussion of safe versus unsafe operations, but as I recall, you can specifically instruct the Lisp compiler to ignore array bounds checking at the expense of speed. You'd have to be insane to do this, however, but it is possible. Consider this function:
(defun bar (array i x) "Set the Ith element of array ARRAY to X"
That does indeed cause various memory errors under SBCL.
OTOH, if we were to specify safety 3 and speed 0 in that function, an error would be signaled and all would be well.
Lisp is a great language, but the Scheme is too simple and lacks a real packaging system, and Common Lisp suffers from C++-style overcomplexity. (Take the mess that is the intersection of the vector, simple-vector, array and simple-array types for example.)
CL's macro system allows these flaws to be overcome, but it's still an overcomplex PITA sometimes.
Slashdot Mirror
I, for one, am automatically suspicious of arguments that begin with "people have done research." Who are these anonymous people? Where was the research published? Has it been repeated? You're appealing to a nonsense authority.
Are you saying that someone shouldn't be able to present an argument? The point of a common law system like ours is the ability to adapt the law to the facts of a particular case. By passing laws like this, we simply limit the judge's ability to do his job. As a result, we'll have coarser justice. If a judge is letting people off for texting while driving and the people really disagree with that, then that judge will be replaced. And who knows? Someone might indeed deserve to be cleared of the charge.
And I bet 90% of the bad drivers you see are listening to music. Let's ban that in cars too. The fact is that when you notice that somebody is driving badly, you tend to look for someone to blame that driving on.
For example,
But you don't notice all the poor, black, or female people who are in fact excellent drivers. The same idea applies to cell phones. Most people can drive well and use cell phones responsibly. You just don't notice these people.
Furthermore, it won't change the fact that society as a whole accepts the practice, and that the law is the work of a vocal minority. I live in New York, and we've banned cell phone conversations in cars for some time now. Yet people think of it as wrong in the same sense that driving five miles per hour over the speed limit is wrong -- that is, not morally wrong at all.
Contrast that with how people feel about drunk driving -- if you tell friends you drive drunk, they'll give you the look they'd give you if you told them you killed kittens as a hobby. The difference is that drunk driving is a real danger.
*sigh* In more general terms, the law should reflect the morality of society as a whole. When someone not wrong is made illegal, the credibility of the law is diminished. People lose respect for all laws, not just the ridiculous one. They become cynical; participation in government drops as people feel that they can't affect their own government. The government abuses that cynical indifference to grab even more power, and the cycle repeats and repeats until we live in an authoritarian police state. It's happened before and it's happening again.
If these kinds of driving things really are wrong enough to warrant laws of their own, then the public needs to be educated FIRST. If they don't clamor all over their legislators to pass the law on their own, then perhaps the law isn't needed in the first place.
Yes, but how many of those third world volunteers would be qualified? What about training costs, communication barriers, and so on?
Arthur C Clark addressed this issue in Songs of Distant Earth, actually. I was impressed. His solution? Put a big chunk of ice in front of the spacecraft and let it ablate away as the craft encounters bits of space debris; in fact, the plot involves the need to obtain another ice shield.
And who do you make license the patent? Everyone who downloads the source tarball? Licensing requires distribution restrictions, and that's antithetical to the whole idea of open source software. It can't work.
${X} is exactly the same as $X for any X, including @. You almost always want to use "$@".
nice -n -19 ionice -c 1 /usr/bin/kplayer "$@"
Quoting the $@ is necessary to ensure that file names with spaces are passed as single words.
Not everything in poor taste ought to be illegal; that you can't think of something you'd be prosecuted under probably means that you couldn't be prosecuted for anything -- shunned, maybe, or rebuked. I don't think there's anything illegal about that statement. If we try to outlaw people becoming offended, then we'll have to also outlaw the kind of free expression that let us develop into what we are today.
Oops! Yes! Thanks... I posted that before I'd had Coffee this morning. Somehow my comment still got modded up though.
The phrase you want to use is "raises the question," not "begs the question." The latter refers very specifically to circular reasoning, which isn't what you meant to describe.
That's going to fail miserably for AOL users at least --- the same user session can result in requests from many different proxies, each with a different IP address.
Also, the "PHP session ID" _is_ stored in a cookie. How else would it work?
I keep seeing this point labored again and again, yet it's simply not true. The assumption of having only 80 years of uranium only applies if 1) you consider only the reserves available at current market prices, a minuscule fraction of the world's total known reserves, and 2) don't consider the use of breeder reactors, which process fuel ~100 times more efficiently than conventional light water reactors do.
_ supply. html
Plus, there's thorium, which is three times as common as uranium and also fissile.
Sources:
http://www.nuclearfaq.ca/cnf_sectionG.htm#uranium
http://www-formal.stanford.edu/jmc/progress/cohen
http://www.world-nuclear.org/info/inf75.html
At least in the RPM-speaking world, we already have this functionality in the SRPM, though not in a formalized sense. Often, compile-time options require only very small changes to the spec, or can be given on the command line. For example, the bytecode compiler option for most freetype RPM packages falls into this category.
I believe that the set of people who want to go gung-ho securing their boxes, who know what they're doing, AND who can't be bothered to recompile packages from SRPM form is very small.
Or you can simply not handle the recompilation bit at all and eliminate all the needless complexity you've described involving handling changed dependencies.
Going with your lDAP example, just always install the LDAP libraries. What's the harm? A few kilobytes of disk space in exchange for a much-simplified package system is a perfectly acceptable tradeoff. If by installing LDAP you eliminate a huge headache involving recompiling half the distribution, you win --- and it's not as if this LDAP functionality is actually used unless specifically enabled, and as an admin, I save time.
To carry the example to a silly extreme, why not have the distribution check what libc functions each application used and recompile it dynamically? After all, why include fchdir(2) if nobody uses it?
For modules that can't be handled with the always-install approach, a plugin architecture is more appropriate, in which packages are detected and loaded at runtime, and specific small packages for each module exist. For example, Redhat-family distributions use this approach for cyrus-sasl authentication methods, and it works well.
There's no need to introduce the needless complexity and computational expense of automatic recompilation.
Don't you fucking see that it DOESN'T MATTER what's causing the climate change? The reality is now indisputable, and must be dealt with if we're to avoid massive human suffering regardless of whether the cause is natural or man-made. There are options that must be considered, and this pointless bickering is just getting in the way.
Red Hat has commercial interests, and the corporation goes out of its way to neuter the software that ships with its distribution. Stock xine, xmms, and so on are fully capable.
An open-source project would never deliberately restrict its feature set in order to appease some corporation; whatever is technologically possible gets implemented. Corporations trying to limit technologically-possible things by gentleman's agreement is figuratively putting a very small finger in a very large dike; eventually, the whole thing will come down.
Idiots at my school keep asking about Vista, and are eager to install it. Fools. Don't people know it's a bad idea to install any new piece of software right away?
Where does all this money go, then? It can't just evaporate into thin air...
Why is that?
Let me rant for a while.
.NET or "Visual C++" to write new client software. It's no wonder that open-source code is such anathama here that no kernel code at all is seen as a better alternative.
In my "university"'s operating systems class, we didn't even write any kernel code or read any open operating system's source. All labs were accomplished by using ordinary processes to simulate parts of a generic operating system kernel, though in previous years, some custom hacked-together simulation was used instead. Then again, this place is so deeply steeped in Microsoft culture that the only real debates are over whether to use
The license may allow it, but the _law_ does (the home recording act of 1992), and the law trumps a private contract.
This paper is absolutely ridiculous, and its author is scaremongering --- if you have access to a site's scripting system via some cross-site vulnerability, then you don't _need_ to subvert an object's prototype to change its behavior. If you're relying on client-side code of any sort, be it written in Javascript or C, for security, you're up a creek without a paddle anyway. Oh nooes, man in the middle proxy attacks! Oh noes, browser bugs allowing javascript to leak outside its security context! There is no security vulnerability in this paper that hasn't been known and worked around for years. I'm wondering what kind of agenda the author has in writing this, actually.
So what if you have to provide the source for InnoDB? There's a process boundary between InnoDB and the program that uses the database. Why would you have to provide the source for your program that only communicated with MySQL over IPC, even under the GPLv3?
Lisp is all that safe a language, and can be somewhat strange: I'm a little confused by the specification's discussion of safe versus unsafe operations, but as I recall, you can specifically instruct the Lisp compiler to ignore array bounds checking at the expense of speed. You'd have to be insane to do this, however, but it is possible. Consider this function:
(defun bar (array i x)
"Set the Ith element of array ARRAY to X"
(declare (type fixnum i)
(type (simple-array fixnum) array)
(optimize (speed 3)
(safety 0)))
(setf (aref array i) x))
Now, let's test it:
(let ((x (coerce '(0 1 2 3)
'(array fixnum 1))))
(bar x -4 31)
x)
That does indeed cause various memory errors under SBCL.
OTOH, if we were to specify safety 3 and speed 0 in that function, an error would be signaled and all would be well.
Lisp is a great language, but the Scheme is too simple and lacks a real packaging system, and Common Lisp suffers from C++-style overcomplexity. (Take the mess that is the intersection of the vector, simple-vector, array and simple-array types for example.)
CL's macro system allows these flaws to be overcome, but it's still an overcomplex PITA sometimes.