This is just one more reason these dumpfkofen have an economy worse than the US.
Dummkopfen, sie dummkopf!
(Yes, I'm quite sure I used the wrong second-person pronoun. Y'know, Germany, English used to have more than one of those, too, but we got rid of the extras 'cause they're STUPID! Get with the program, already.)
They are talking about typing something into a field labeled "Search your computer and online sources.
Call me crazy, but I normally have a real good idea whether I'm searching for something on my computer or on the interwebz. And the only use case I can think of where I'd ever want to search both for the same thing is if I want to run an app (say, Google Earth) that may or may not be installed, so I want to find and execute the installed instance, if any, and failing that, I'll search the web to find and download the installer. Even then, I want to search first one, then conditionally search the other.
So to me it's pretty obvious that the more useful behavior is two search boxen, one to search my computer, and the other to search online sources. Or perhaps one search box with two buttons, so I can click the local one, and if I don't get a result, click the web one.
But, why in Kropotkinsname would anyone want to disable the online search? If you want to get the weather, calculation, wikipedia page, wouldn't you just lookup the result on the web instead? Or even worse: search it with Google?
Well, there's two points of objection. One is an issue of how many and whose computers see your search queries -- which is ultimately addressable by changing which sources are enabled. In order to do an internet search, you've obviously gotta trust somebody with your search query -- so pick somebody and set up your sources correspondingly.
The other, and IMO bigger point, is that somebody -- whether it's canonical's search service, google, duckduckgo, or ixquick -- is receiving info every time you use that tool to search for a local document. No matter how much I trust ixquick, it's senseless to entrust them with more data in exchange for no benefit, so when I know I'm searching for a local file, I'd like the easy choice to not have my search query posted to any web search engine. Again, give me two search boxes, or one box with two (or more -- one for each source, one for all sources, etc.) buttons.
Harshly stated, but in essence, true: Linux has to generate income. Android does it with massive, unavoidable invasion of privacy. Ubuntu does it with a minor, transparent and easily disabled intrusion into some of your online life.
Debian does it with volunteer work where possible, and donations for stuff (e.g. hosting) that needs money.
Arch does it with a similar volunteer/donation scheme.
Uncle Pat does it with stability and simplicity, to the exclusion of modernity (e.g. still no PAM, no sysv init scripts, and you bet your life no systemd/upstart) -- and enough people want this option to remain available that they voluntarily buy CD sets (in lieu of downloading ISOs) or slackware-branded merchandise, in sufficient amounts to pay the bills for Pat.
But yeah, if you're making a distro that doesn't appeal to either the sort of people who can volunteer useful help, or the sort who are willing to donate money (whether structured as a "donation", or as the "purchase" of physical media), I guess maybe you have to hope they're the sort who'll barter away their privacy for software. Since I am the sort who has donated and will continue to donate to projects I'd rather didn't die, I by definition don't care about projects that need to monetize my privacy to continue existing.
Or if you're greedy^Wprofit-oriented, and therefore want more income than people are willing to donate, you might have to seek alternate income sources such as users giving up their privacy. But I don't care about that, because IMO I'm a lot better off using a distro made by people focusing on making a good distro, than one made by people focusing on making a big profit. But what do I know, I'm one of those crazy* right-libertarians who believes the only thing better than a (reasonably small) company, driven to make a good product by competition and the greed/profit motive, is a (reasonably small) co-op, driven to make a good product by the members' individual motive to benefit from the goodness of the product they themselves both make and use.
I believe both preceeding cases describe Canonical, a for-profit company making an OS that's wildly popular with freeloading "end-user" types -- so I don't question the economic sense (for Canonical) of resorting privacy-monetization, and I don't really mind that they and their non-privacy-valuing users make that voluntary trade. OTOH, for the reasons stated, I also don't care whether Canonical disappears from the face of the Earth, so if I find myself, for whatever reason, using an Ubuntu machine, you can bet I'm turning it off.
*craziness measured relative to my fellow US right-libertarians, to most of whom "co-op" is a four-letter word. I have seriously heard the sentence "I can see why you'd want such a thing, but a co-op just feels too socialist for me." Yeah, we're all about the individual liberties, economic freedom of voluntary association, etc., but the moment a few guys want to voluntarily associate into a certain class of organization, without imposing it on anyone else, we knee-jerk and cry "socialist"?! </political-rant>
Yes, it's true! Street lights use exactly the same bulbs as your home lighting fixtures, so we can expect they'll use exactly the same dollar-store 3W LED bulbs that you've seen.
Or maybe, since streetlights actually use 200W-1000W HID bulbs, the LED replacement they're talking about will have virtually nothing in common with the LED bulbs you're talking about, so you're really talking without a clue...
That's terrible for LEDs with circuitry designed for continuous operation. It shouldn't be an issue in traffic lights, because the LED units used there are designed for that purpose anyway (it's not like they're dropping in a A19 household LED bulb), so the ballast should be designed for it.
In the US, the auto-sear approach is definitely the smart-criminal move, because it lets you convert legal, and thus readily-available, semi-automatic weapons to full-auto, and ammo's available with no identity check or anything.
In the UK, this is less obviously a smart move, because semi-autos are rather hard to come by, and AIUI ammo sales are restricted -- if you and your buddies have one readily convertable semi-auto amongst you, it may be more beneficial to make you each three or four single-shot disposable guns than to convert that one gun to full-auto, and then pay black-market premiums on the increased ammo consumption because you don't have a firearm certificate.
Re: It was already a dangerous site to visit ...
on
PHP.net Compromised
·
· Score: 1
It could be prevented by simply requiring that operations that return a value inside an evaluation must be enclosed with braces: 'if ({a = b})' would evaluate, then proceed; 'if (a == b)' would compare then proceed; 'if (a = b)' would fail.
Huh? 'a==b' returns a value every bit as much as 'a=b', so under that definition, why mustn't it also be enclosed in braces? Now I wouldn't say either of them "returns" anything -- functions return values, while expressions evaluate to values -- but definitions do vary and it would be silly to nitpick over. The point, though, is that there's no sense of the term "return" in which "a=b" returns a value and "a==b" doesn't.
You've also just clumsily overloaded C syntax, as a brace-delimited block doesn't "evaluate" to the return value of the last statement within the block. It doesn't evaluate to anything at all (C is an imperative language through-and-through), so using them to evaluate expressions is ugly and non-intuitive.
I'm not saying that the syntax shouldn't have been fixed (personally, I remain unconvinced about the syntax, though changing the symbols (e.g. = ->:= and == -> =) would definitely have been good), but a syntax fix needs to be more complicated than you seem to think it is, and therefore less obviously-correct.
In case you don't get why the complexity would have been a downside then (it wouldn't be today, IMO), remember the C language was created in an age when many programmers didn't have the luxury of an interactive teletype session. This means you can't afford to say "Was it a:(foo && {return = bar(x)}) or b:{foo && (return = bar(x))}? Bother, I'll just put in a and change it if the compiler yells at me.", because you don't get compiler feedback immediately. Complicating the syntax decreases the odds of the programmer remembering it right off, and thus increases the time the programmer has to spend looking it up.
Also remember that even though they are muck lighter, bikes suck at stopping compared to vehicles.
This is not normal; if your bike's stopping performance seems more than slightly inferior to cars around you, you have a problem, and for your own safety need to solve it. If you're squeezing the front brake as hard as you can, and it's still rolling to a stop, you need to find what's wrong with your front brake and fix it. If you're locking up the front wheel and skidding, but still not stopping as short as cars braking from the same speed, you need tires suited to road conditions. (Perhaps you're running off-road tires on the road?) If the brakes can do more, but you're holding back, then you probably need to learn to shift your weight aft when you brake, allowing you to brake harder without risk of flying over the bars.
Think tire surface area contacting the pavement and mass.
Just... No. (Note that Coulomb friction, aka dry friction, is a pretty good model for tire/roadway friction over a wide range of conditions and will be assumed from here out.)
Surface area has basically nothing to do with it. See, less area in contact with the same force pushing down just means more normal pressure in that area, which means you can generate more stopping force per unit area -- the area cancels out exactly.
The mass also cancels: If you weigh twice as much, you get twice the normal force, so you get twice the stopping force; comparing F=m*a with 2F=2m*a, the acceleration is the same.
There's two parameters that practically matter, for both motor vehicles and bicycles -- they each set a limit to the deceleration possible, and the lower limit applies (naturally).
* First is the coefficient of static friction -- this determines the point at which the wheel will start to lock up and slide. This depends on the roadway type and condition, the tire material, and the tread design.
* Second is the angle from the front axle to the vehicle's center of mass, which limits the deceleration possible before the vehicle begins to rotate upwards about the front axle instead of slowing. This is a simple function of vehicle design in cars, where the driver is a negligible contribution to vehicle mass, but is largely controlled by rider posture in cycling. In both cases (assuming, in the bicycle case, a skilled rider not attempting stunts), this is ordinarily the higher of the two limits, so that the vehicle goes into a skid rather than an endo, because that's a lot easier to recover from.
So basically, there's no reason to expect either vehicle to be substantially better at stopping than the other, provided they both have good tires, suited to road conditions. And in my experience, this turns out to be true -- in my younger days, I've actually engaged in stunts in a parking lot to demonstrate this; a bike and a car keeping pace side-by-side at 15-20mph, another car's horn serves as the signal for both to stop, and then we both brake hard, racing to stop in the shortest distance/time. It's invariably within 10%, with reaction time seeming to be the biggest factor. Again, if your bike "suck[s] at stopping", there's something with your bike or with the way you're using it.
1. Check the Minimum HPLIP version and make sure your distribution and version have at least this
Y'know, if you just buy a postscript-compatible printer, you won't need hplip. Or any other software running on your system. If the printer's own brain is too weak to handle postscript, the manufacturer can bloody well stick their special driver on a computer and stick it in the printer case!
Printer support isn't/shouldn't be "a coincidence"; there's an industry-wide lingua franca that anybody can implement in their printers, and there's no good reason to buy a printer that doesn't speak it.
Yes, for very low print volumes, lasers are still cheaper because they still work when you need them. Inkjet printers are often clogged up after a few weeks without printing. If you can get them to work with the built-in cleaning, it costs a fortune in ink.
Hello, welcome to 1979. The latest release of UNIX has a new daemon (thanks, Brian Kernighan) that lets you automatically run any number of tasks on specified schedules!
Just add a line to/usr/etc/crontab,* and it can run a standard print once a week -- by flushing the printhead before it's dried the whole way, you don't need the ink wastage of a full print-head cleaning cycle.
* If you're in fact not living in 1979, but merely unaware of such a daemon's existence and/or of its applicability to the situation at hand, hello future-person! Be aware that your minicomputer may have a different version of UNIX (or even some UNIX-compatible but legally not-UNIX OS), so you might need to check/etc/crontab instead.
My experience with Brothers is limited to laser MFDs, but with that caveat:
Some Brothers support postscript (under the term "BR-Script" because trademark law is hilarious), and those ones are great. Download the.ppd, and boom, you're running -- Just Like It Should Be. Some of them don't, and it's a bloody circus getting their drivers up and running.
The hardware's solid, I've really got no complaints in this regard, about either the castrated or ps-supporting versions. But if the model you're looking at doesn't support "BR-script", run away or you will have cause to tear out your hair.
2. The plaintiffs were planning on selling/licensing/etc the software to third parties, which would no longer be possible if the source was freely available.
This must be why MS has been unable to sell any copies of Windows, ever since that source leak a decade ago? OTOH, just maybe, since copyright law prohibits this guy from distributing it, anyone who cares enough to obey the law in the first place will still have to buy the software from his former employer, nobody will be able to contribute to the "open-source project" he creates without opening themselves up to lawsuits, and he'll get taken for all he's worth for copyright infringement statutory damages -- or, in the incredibly unlikely case that actual damages are higher than statutory, he'll get hit with those instead.
I'm not saying that the guy releasing the source code (with or without a fraudulent copyright claim and license offer) wouldn't cause some harm to the company, but you're way overstating the harm.
Facebook should get out of the censorship/banning business. You should only be able to report things that are against the law, e.g., child pornography.
Devil's advocate: I'd rather not have Facebook telling people "We only remove illegal content; if you don't wanna see beheading videos, take it up with your Congressman.", because it's all too believable that some congressclown would take up the challenge, and push through legislation making such content illegal.
The rest of the internet is clearly better off if prominent sites such as Facebook engage in censorship, because this reduces the number of idiots getting riled about it and therefore the odds that the government applies censorship to the whole internet. Now whether this benefit to the rest of the internet is worth the harm of having Facebook censored is... debatable, at best, but there is a not-absurd argument there.
Cars that run on bio-diesel are only carbon-negative if they're running rich, sequestering carbon as lovely black soot!
Normally, they're considered carbon-neutral, because they release the same amount of CO2 that the soy plants just took out of the atmosphere and converted to soybean oil. Think of it as a short-term interest-free loan -- pull some CO2 out, convert the C in it to hydrocarbon fuel, then convert it back to CO2 in a diesel engine and release it; no net increase in CO2 levels.
Yeah, no. The point is that you run it on biomass, so the whole cycle is carbon-neutral or carbon-negative:
CO2 + H2O --photosynthesis-> biomass --power-pallet-> CO2 + H2O + charcoal
Stop there, and you've got some energy out, and if you bury the charcoal, it's carbon-negative. Or use the charcoal as fuel, e.g. for cooking/heating (hopefully replacing fossil fuel currently used in those roles), and you get
CO2 + H2O --photosynthesis-> biomass --power-pallet-> CO2 + H2O + charcoal --charcoal-burning-> CO2 + H2O
Which is carbon neutral, bringing us right back where we started.
The only way you can call it "only carbon-reduced" is if you don't look at the whole cycle, or if you're actually feeding it fossil hydrocarbons instead of biomass, and not burning the coal that comes out -- and it's not clear that that would make any economic sense.
No I'm complaining because slashdot took a perfectly valid absolute URL and somehow munged it into something other than what I'd entered before pressing submit. The only difference between that post and the dozens of others I've made previously is that I was using a tablet to do it. Fucked if I know why they would do something different to html embedded in a post from a tablet versus a desktop but I know what was in the textarea before I sumbitted and it sure as fuck was an absolute url with wikipedia in the hostname section.
Well, that was convincing. Wait, it actually wasn't -- the tablet view doesn't munge anyone else's absolute URLs into relative ones, so why would it single yours out? That just doesn't make sense, no mattery how many times you say "fuck".
The difference might be that because of the different browser on the tablet, when you tried to select the whole thing and copy it to paste it into/., it didn't get the scheme part of the URL (along with the separating : and the// prefix, i.e. "http://" or similar) and you failed to notice it. (You go on about "wikipedia in the hostname section" without even mentioning the scheme section -- given that the latter is the only difference between the absolute and relative URLs I linked before, it seems you may have missed the point.)
Or it could be that/. singled your particular post out for abuse that it doesn't apply to other posts, and doesn't have any reason to apply to any post ever.
p.s. this comment posted with the tablet interface, just for you -- see how the link above works fine? It was generated by <a href="http://en.wikipedia.org/wiki/Occam's_razor">I'm gonna go with the first one</a>
There's plenty of things wrong with the tablet interface, but the URL-munging you accuse it of isn't one of them.
Fucking slashdot changed my links from wikipedia to slashdot.
Are you complaining because/. lacks a <DWIM> tag, along with the strong AI that implies? Or because someone failed to teach you about absolute and relative URLs?
Either way, it seems a little unreasonable to blame/. for it.
(Now the tablet UI, I'm with you all the way blaming/. for that abomination. If you have the ability, changing to a desktop user-agent string will get around it -- but there's NO reason we should have to do that.)
Remember, kids, long half-life means decay events are rare, meaning low cancer risk.
Any single radioisotope can be either highly radioactive or last for thousands of years; both at once is impossible. (Nuclear waste, of course, contains various isotopes of both sorts, and some in the middle -- this complicates fuel reprocessing and cleanup of shutdown or failed reactors, as you have to contain it, wait a few years for the short-half-life stuff to decompose, then deal with the long-half-life stuff.)
Well, then. If some AC says he personally disproved something, without bothering the paper he published on it, the methods used to disprove it, or basically anything else... why wouldn't everyone believe him over TFA?
Slashdot Mirror
When taking apart my Galaxy SIII, I discovered that the camera modules were incredibly easy to remove. Of course this wouldn't be true of all phones.
It's true of most phones, though.
This is just one more reason these dumpfkofen have an economy worse than the US.
Dummkopfen, sie dummkopf!
(Yes, I'm quite sure I used the wrong second-person pronoun. Y'know, Germany, English used to have more than one of those, too, but we got rid of the extras 'cause they're STUPID! Get with the program, already.)
Ah, yes, it's Austria, not Australia. s/kangaroo/kangoo/g Fixed.
> Ubuntu does it with a minor
Hey, I don't like Ubuntu either, but accusing them of statutory rape seems a little harsh!
They are talking about typing something into a field labeled "Search your computer and online sources.
Call me crazy, but I normally have a real good idea whether I'm searching for something on my computer or on the interwebz. And the only use case I can think of where I'd ever want to search both for the same thing is if I want to run an app (say, Google Earth) that may or may not be installed, so I want to find and execute the installed instance, if any, and failing that, I'll search the web to find and download the installer. Even then, I want to search first one, then conditionally search the other.
So to me it's pretty obvious that the more useful behavior is two search boxen, one to search my computer, and the other to search online sources. Or perhaps one search box with two buttons, so I can click the local one, and if I don't get a result, click the web one.
But, why in Kropotkinsname would anyone want to disable the online search? If you want to get the weather, calculation, wikipedia page, wouldn't you just lookup the result on the web instead? Or even worse: search it with Google?
Well, there's two points of objection. One is an issue of how many and whose computers see your search queries -- which is ultimately addressable by changing which sources are enabled. In order to do an internet search, you've obviously gotta trust somebody with your search query -- so pick somebody and set up your sources correspondingly.
The other, and IMO bigger point, is that somebody -- whether it's canonical's search service, google, duckduckgo, or ixquick -- is receiving info every time you use that tool to search for a local document. No matter how much I trust ixquick, it's senseless to entrust them with more data in exchange for no benefit, so when I know I'm searching for a local file, I'd like the easy choice to not have my search query posted to any web search engine. Again, give me two search boxes, or one box with two (or more -- one for each source, one for all sources, etc.) buttons.
Harshly stated, but in essence, true: Linux has to generate income. Android does it with massive, unavoidable invasion of privacy. Ubuntu does it with a minor, transparent and easily disabled intrusion into some of your online life.
Debian does it with volunteer work where possible, and donations for stuff (e.g. hosting) that needs money.
Arch does it with a similar volunteer/donation scheme.
Uncle Pat does it with stability and simplicity, to the exclusion of modernity (e.g. still no PAM, no sysv init scripts, and you bet your life no systemd/upstart) -- and enough people want this option to remain available that they voluntarily buy CD sets (in lieu of downloading ISOs) or slackware-branded merchandise, in sufficient amounts to pay the bills for Pat.
But yeah, if you're making a distro that doesn't appeal to either the sort of people who can volunteer useful help, or the sort who are willing to donate money (whether structured as a "donation", or as the "purchase" of physical media), I guess maybe you have to hope they're the sort who'll barter away their privacy for software. Since I am the sort who has donated and will continue to donate to projects I'd rather didn't die, I by definition don't care about projects that need to monetize my privacy to continue existing.
Or if you're greedy^Wprofit-oriented, and therefore want more income than people are willing to donate, you might have to seek alternate income sources such as users giving up their privacy. But I don't care about that, because IMO I'm a lot better off using a distro made by people focusing on making a good distro, than one made by people focusing on making a big profit. But what do I know, I'm one of those crazy* right-libertarians who believes the only thing better than a (reasonably small) company, driven to make a good product by competition and the greed/profit motive, is a (reasonably small) co-op, driven to make a good product by the members' individual motive to benefit from the goodness of the product they themselves both make and use.
I believe both preceeding cases describe Canonical, a for-profit company making an OS that's wildly popular with freeloading "end-user" types -- so I don't question the economic sense (for Canonical) of resorting privacy-monetization, and I don't really mind that they and their non-privacy-valuing users make that voluntary trade. OTOH, for the reasons stated, I also don't care whether Canonical disappears from the face of the Earth, so if I find myself, for whatever reason, using an Ubuntu machine, you can bet I'm turning it off.
*craziness measured relative to my fellow US right-libertarians, to most of whom "co-op" is a four-letter word. I have seriously heard the sentence "I can see why you'd want such a thing, but a co-op just feels too socialist for me." Yeah, we're all about the individual liberties, economic freedom of voluntary association, etc., but the moment a few guys want to voluntarily associate into a certain class of organization, without imposing it on anyone else, we knee-jerk and cry "socialist"?! </political-rant>
Yes, it's true! Street lights use exactly the same bulbs as your home lighting fixtures, so we can expect they'll use exactly the same dollar-store 3W LED bulbs that you've seen. Or maybe, since streetlights actually use 200W-1000W HID bulbs, the LED replacement they're talking about will have virtually nothing in common with the LED bulbs you're talking about, so you're really talking without a clue...
That's terrible for LEDs with circuitry designed for continuous operation. It shouldn't be an issue in traffic lights, because the LED units used there are designed for that purpose anyway (it's not like they're dropping in a A19 household LED bulb), so the ballast should be designed for it.
In the US, the auto-sear approach is definitely the smart-criminal move, because it lets you convert legal, and thus readily-available, semi-automatic weapons to full-auto, and ammo's available with no identity check or anything. In the UK, this is less obviously a smart move, because semi-autos are rather hard to come by, and AIUI ammo sales are restricted -- if you and your buddies have one readily convertable semi-auto amongst you, it may be more beneficial to make you each three or four single-shot disposable guns than to convert that one gun to full-auto, and then pay black-market premiums on the increased ammo consumption because you don't have a firearm certificate.
It could be prevented by simply requiring that operations that return a value inside an evaluation must be enclosed with braces: 'if ({a = b})' would evaluate, then proceed; 'if (a == b)' would compare then proceed; 'if (a = b)' would fail.
Huh? 'a==b' returns a value every bit as much as 'a=b', so under that definition, why mustn't it also be enclosed in braces? Now I wouldn't say either of them "returns" anything -- functions return values, while expressions evaluate to values -- but definitions do vary and it would be silly to nitpick over. The point, though, is that there's no sense of the term "return" in which "a=b" returns a value and "a==b" doesn't.
You've also just clumsily overloaded C syntax, as a brace-delimited block doesn't "evaluate" to the return value of the last statement within the block. It doesn't evaluate to anything at all (C is an imperative language through-and-through), so using them to evaluate expressions is ugly and non-intuitive.
I'm not saying that the syntax shouldn't have been fixed (personally, I remain unconvinced about the syntax, though changing the symbols (e.g. = -> := and == -> =) would definitely have been good), but a syntax fix needs to be more complicated than you seem to think it is, and therefore less obviously-correct.
In case you don't get why the complexity would have been a downside then (it wouldn't be today, IMO), remember the C language was created in an age when many programmers didn't have the luxury of an interactive teletype session. This means you can't afford to say "Was it a: (foo && {return = bar(x)}) or b: {foo && (return = bar(x))}? Bother, I'll just put in a and change it if the compiler yells at me.", because you don't get compiler feedback immediately. Complicating the syntax decreases the odds of the programmer remembering it right off, and thus increases the time the programmer has to spend looking it up.
Also remember that even though they are muck lighter, bikes suck at stopping compared to vehicles.
This is not normal; if your bike's stopping performance seems more than slightly inferior to cars around you, you have a problem, and for your own safety need to solve it. If you're squeezing the front brake as hard as you can, and it's still rolling to a stop, you need to find what's wrong with your front brake and fix it. If you're locking up the front wheel and skidding, but still not stopping as short as cars braking from the same speed, you need tires suited to road conditions. (Perhaps you're running off-road tires on the road?) If the brakes can do more, but you're holding back, then you probably need to learn to shift your weight aft when you brake, allowing you to brake harder without risk of flying over the bars.
Think tire surface area contacting the pavement and mass.
Just... No. (Note that Coulomb friction, aka dry friction, is a pretty good model for tire/roadway friction over a wide range of conditions and will be assumed from here out.)
Surface area has basically nothing to do with it. See, less area in contact with the same force pushing down just means more normal pressure in that area, which means you can generate more stopping force per unit area -- the area cancels out exactly.
The mass also cancels: If you weigh twice as much, you get twice the normal force, so you get twice the stopping force; comparing F=m*a with 2F=2m*a, the acceleration is the same.
There's two parameters that practically matter, for both motor vehicles and bicycles -- they each set a limit to the deceleration possible, and the lower limit applies (naturally).
* First is the coefficient of static friction -- this determines the point at which the wheel will start to lock up and slide. This depends on the roadway type and condition, the tire material, and the tread design.
* Second is the angle from the front axle to the vehicle's center of mass, which limits the deceleration possible before the vehicle begins to rotate upwards about the front axle instead of slowing. This is a simple function of vehicle design in cars, where the driver is a negligible contribution to vehicle mass, but is largely controlled by rider posture in cycling. In both cases (assuming, in the bicycle case, a skilled rider not attempting stunts), this is ordinarily the higher of the two limits, so that the vehicle goes into a skid rather than an endo, because that's a lot easier to recover from.
So basically, there's no reason to expect either vehicle to be substantially better at stopping than the other, provided they both have good tires, suited to road conditions. And in my experience, this turns out to be true -- in my younger days, I've actually engaged in stunts in a parking lot to demonstrate this; a bike and a car keeping pace side-by-side at 15-20mph, another car's horn serves as the signal for both to stop, and then we both brake hard, racing to stop in the shortest distance/time. It's invariably within 10%, with reaction time seeming to be the biggest factor. Again, if your bike "suck[s] at stopping", there's something with your bike or with the way you're using it.
1. Check the Minimum HPLIP version and make sure your distribution and version have at least this
Y'know, if you just buy a postscript-compatible printer, you won't need hplip. Or any other software running on your system. If the printer's own brain is too weak to handle postscript, the manufacturer can bloody well stick their special driver on a computer and stick it in the printer case! Printer support isn't/shouldn't be "a coincidence"; there's an industry-wide lingua franca that anybody can implement in their printers, and there's no good reason to buy a printer that doesn't speak it.
Yes, for very low print volumes, lasers are still cheaper because they still work when you need them. Inkjet printers are often clogged up after a few weeks without printing. If you can get them to work with the built-in cleaning, it costs a fortune in ink.
Hello, welcome to 1979. The latest release of UNIX has a new daemon (thanks, Brian Kernighan) that lets you automatically run any number of tasks on specified schedules!
Just add a line to /usr/etc/crontab,* and it can run a standard print once a week -- by flushing the printhead before it's dried the whole way, you don't need the ink wastage of a full print-head cleaning cycle.
* If you're in fact not living in 1979, but merely unaware of such a daemon's existence and/or of its applicability to the situation at hand, hello future-person! Be aware that your minicomputer may have a different version of UNIX (or even some UNIX-compatible but legally not-UNIX OS), so you might need to check /etc/crontab instead.
My experience with Brothers is limited to laser MFDs, but with that caveat: Some Brothers support postscript (under the term "BR-Script" because trademark law is hilarious), and those ones are great. Download the .ppd, and boom, you're running -- Just Like It Should Be. Some of them don't, and it's a bloody circus getting their drivers up and running.
The hardware's solid, I've really got no complaints in this regard, about either the castrated or ps-supporting versions. But if the model you're looking at doesn't support "BR-script", run away or you will have cause to tear out your hair.
2. The plaintiffs were planning on selling/licensing/etc the software to third parties, which would no longer be possible if the source was freely available.
This must be why MS has been unable to sell any copies of Windows, ever since that source leak a decade ago? OTOH, just maybe, since copyright law prohibits this guy from distributing it, anyone who cares enough to obey the law in the first place will still have to buy the software from his former employer, nobody will be able to contribute to the "open-source project" he creates without opening themselves up to lawsuits, and he'll get taken for all he's worth for copyright infringement statutory damages -- or, in the incredibly unlikely case that actual damages are higher than statutory, he'll get hit with those instead.
I'm not saying that the guy releasing the source code (with or without a fraudulent copyright claim and license offer) wouldn't cause some harm to the company, but you're way overstating the harm.
Facebook should get out of the censorship/banning business. You should only be able to report things that are against the law, e.g., child pornography.
Devil's advocate:
I'd rather not have Facebook telling people "We only remove illegal content; if you don't wanna see beheading videos, take it up with your Congressman.", because it's all too believable that some congressclown would take up the challenge, and push through legislation making such content illegal.
The rest of the internet is clearly better off if prominent sites such as Facebook engage in censorship, because this reduces the number of idiots getting riled about it and therefore the odds that the government applies censorship to the whole internet. Now whether this benefit to the rest of the internet is worth the harm of having Facebook censored is ... debatable, at best, but there is a not-absurd argument there.
Because it has C-x M-c M-butterfly.
Cars that run on bio-diesel are only carbon-negative if they're running rich, sequestering carbon as lovely black soot! Normally, they're considered carbon-neutral, because they release the same amount of CO2 that the soy plants just took out of the atmosphere and converted to soybean oil. Think of it as a short-term interest-free loan -- pull some CO2 out, convert the C in it to hydrocarbon fuel, then convert it back to CO2 in a diesel engine and release it; no net increase in CO2 levels.
Yeah, no. The point is that you run it on biomass, so the whole cycle is carbon-neutral or carbon-negative:
CO2 + H2O --photosynthesis-> biomass --power-pallet-> CO2 + H2O + charcoal
Stop there, and you've got some energy out, and if you bury the charcoal, it's carbon-negative. Or use the charcoal as fuel, e.g. for cooking/heating (hopefully replacing fossil fuel currently used in those roles), and you get
CO2 + H2O --photosynthesis-> biomass --power-pallet-> CO2 + H2O + charcoal --charcoal-burning-> CO2 + H2O
Which is carbon neutral, bringing us right back where we started.
The only way you can call it "only carbon-reduced" is if you don't look at the whole cycle, or if you're actually feeding it fossil hydrocarbons instead of biomass, and not burning the coal that comes out -- and it's not clear that that would make any economic sense.
s/http:/https:/
No I'm complaining because slashdot took a perfectly valid absolute URL and somehow munged it into something other than what I'd entered before pressing submit. The only difference between that post and the dozens of others I've made previously is that I was using a tablet to do it. Fucked if I know why they would do something different to html embedded in a post from a tablet versus a desktop but I know what was in the textarea before I sumbitted and it sure as fuck was an absolute url with wikipedia in the hostname section.
Well, that was convincing. Wait, it actually wasn't -- the tablet view doesn't munge anyone else's absolute URLs into relative ones, so why would it single yours out? That just doesn't make sense, no mattery how many times you say "fuck".
The difference might be that because of the different browser on the tablet, when you tried to select the whole thing and copy it to paste it into /., it didn't get the scheme part of the URL (along with the separating : and the // prefix, i.e. "http://" or similar) and you failed to notice it. (You go on about "wikipedia in the hostname section" without even mentioning the scheme section -- given that the latter is the only difference between the absolute and relative URLs I linked before, it seems you may have missed the point.)
Or it could be that /. singled your particular post out for abuse that it doesn't apply to other posts, and doesn't have any reason to apply to any post ever.
I'm gonna go with the first one
p.s. this comment posted with the tablet interface, just for you -- see how the link above works fine? It was generated by <a href="http://en.wikipedia.org/wiki/Occam's_razor">I'm gonna go with the first one</a> There's plenty of things wrong with the tablet interface, but the URL-munging you accuse it of isn't one of them.
<a href="example.com">...</a>
<a href="http://example.com">...</a>
See the difference?
Fucking slashdot changed my links from wikipedia to slashdot.
Are you complaining because /. lacks a <DWIM> tag, along with the strong AI that implies?
Or because someone failed to teach you about absolute and relative URLs?
Either way, it seems a little unreasonable to blame /. for it.
(Now the tablet UI, I'm with you all the way blaming /. for that abomination. If you have the ability, changing to a desktop user-agent string will get around it -- but there's NO reason we should have to do that.)
OK, feeding a troll here, but this tired misinformation's still making the rounds, and someone's gotta fight it, so here goes...
Don't forget that plutonium 239 has a half life of over 24,000 years and is lethal in minute quantities at only brief exposure time.
Uh, no. It's not.
Remember, kids, long half-life means decay events are rare, meaning low cancer risk.
Any single radioisotope can be either highly radioactive or last for thousands of years; both at once is impossible. (Nuclear waste, of course, contains various isotopes of both sorts, and some in the middle -- this complicates fuel reprocessing and cleanup of shutdown or failed reactors, as you have to contain it, wait a few years for the short-half-life stuff to decompose, then deal with the long-half-life stuff.)
Hey! *I* am a chimera!
Did you seriously just post that without calling GP an insensitive clod?
This is /., we have^Whad standards.
Well, then. If some AC says he personally disproved something, without bothering the paper he published on it, the methods used to disprove it, or basically anything else... why wouldn't everyone believe him over TFA?