The point of the patent sytem is not to make people pay royalties, but to create an incentive for inventors -- if the inventor gets neither the royalties (by licensing the patent) nor the monopoly (by not licensing the patent), there's no incentive, no matter whether those using the patented invention make royalty payments to some other entity or not.
If you've already taken away the inventor's incentive, what possible reason is there for the government's licensing fee?
It's the genetic equivalent of adding the Euro sign into your system fonts.
That's actually a remarkably accurate analogy, if you add the Euro sign at ascii position 0x09 (aka ^I, aka HT) and modify your software (e.g. C compiler) to treat tabs as a normal character instead of whitespace.
Oops, should've used preview... Last paragraph, take 2:
In the end, though, the big issue, and the reason you don't see the |tee fifo| and <fifo idiom used very often, much less foo >fifo1& bar >fifo2& baz fifo1 fifo2, is that UNIX is command-line based, and arbitrary graphs are just plain hard to represent well in a single command line. Naming nodes (i.e. FIFOs) and referring to them later by name does yield a mathematically general representation, but it's nowhere near as intuitive to use as the simple anonymous pipes in foo|bar|more, so it's doomed to neglect.
Except UNIX has a single flow control model for those pipelines,
Yeah.
has difficulty forking data to two places except in very simple cases (tee)
Eh, are you forgetting named pipes, aka fifos? because (foo | tee myfifo | bar)& baz <myfifo and more elaborate versions of that theme seem to be able to handle any complex case I can think of in terms of the simple case.
and cannot join [two] processes together to feed a third.
I'm not quite sure what you mean by this -- if you mean to merge two outputs into the single input of the third process, this is again simple with fifos. (Of course, each of the first two processes' buffering behavior contributes to the order or chaos resulting -- but if everything is buffering i/o a line at a time, and a line is logically a complete packet, it pretty much works.)
If, OTOH, you mean to have a process with two separate inputs (e.g. one for a video stream, one for subtitles to be superimposed on it), this is possible in the UNIX model (simply assign file descriptors higher than 2 in the same way stdin, stdout, and stderr are redirected), and at least some ksh derivatives do support redirecting arbitrary file descriptors; however, few if any of the ordinary UNIX utilities do anything of this sort. In part, this is because there are few uses (that I can think of) for this without enhancing the flow control model or allowing data types other than text; in part, it's because stdin, stdout, and stderr work because they are standardized, therefore there's no preexisting uniform mechanism for e.g. a filter with a variadic inputs (in other words, for each such multi-input program, the user would be responsible to learn what file descriptors correspond to what inputs and outputs, what switches (if any) control those assignments, and keep all this info in their head).
(However, many UNIX utilities do accept multiple filenames as arguments, and these files can in many cases be fifos, so even though it strays from the pure "shell redirects everything" model, you can still do that.)
In the end, though, the big issue, and the reason you don't see the |tee fifo| and <fifo idiom used very often, much less foo >fifo1& bar >fifo2& baz fifo1 fifo2, is that UNIX is command-line based, and arbitrary graphs are just plain hard to represent well in a single command line. Naming nodes (i.e. FIFOs) and referring to them later by name does yield a mathematically general representation, but it's nowhere near as intuitive to use as the simple anonymous pipes in foo|bar|more, so it's doomed to neglect.
Instead, download MythTV, set it to automatically record your favorite actors and shows, and watch pretty much whatever you want, whenever you want, at no cost.
As long as "whatever you want" doesn't include cable shows, overseas shows, or (depending where you live) shows on lesser networks such as the CW that don't have an affiliate in every small city, then sure, PC-based DVR is awesome and free.
Anyway, if OTA programming you can receive in your location with an antenna at your location is all you want to watch, I don't see how you're any more or less of a "free-loading scumbag" to watch it sans ads with a DVR rig (PC-based or not) or to watch it sans ads by downloading a pirated copy. One is legal, the other is illegal, but they have exactly the same effect on the content producer's bottom line.
Android/Chrome here, and there's actually a built-in checkbox to send a desktop UA. Unfortunately (and somewhat incredibly), there's no way to default this checkbox "on" (i.e. you have to click it once in each new tab, to make that tab send a desktop UA), and when you toggle it, it goes back to the last address you typed in the URL field and reloads that, presumably so as to avoid any redirects (e.g. www.example.com -> m.example.com), but also avoiding any deliberate clicks you've made.
When posting the above, I got halfway here before I rembembered to click it, so rather than backtracking, I thought "WTH, let's try/.'s mobile interface again" (tried it for a week back when it was new; didn't like it) -- turns out, there's still no preview button (?!), and it requires manual <p> insertion (instead of line-feeds) to make your comment not one giant paragraph. (Should've known better, yeah...)
So I'm back to clicking that damn checkbox every time and cursing the name of Google.
I really need to get back to tinkering with Arch on here -- I bought a TF700 with that in mind, but got stuck on Android for a while when nobody had dual-boot working with a 4.2-compatible kernel. Once I get Arch back up, I'll be able to go back to normal, desktop browsers. (The mobile versions of both Firefox and Chrome both have insane amounts of deliberate suck that cannot be disabled, no matter how big a screen my "tablet" has, or how many keyboards and mice I have temporarily or semipermanently connected -- I'm running Android, so I must be treated to behavior that's at best arguably suited to a 3.5" keyboardless phone.) Not to whine, but it shouldn't be this much hassle to get an ARM-powered laptop running a normalish GNU/Linux distro -- but maybe I just got spoiled with my N810.
We won the downloadable music DRM wars, you mean. (And possibly the downloadable video one, as well; I'm not involved, so I don't know the state of that.)
The streaming video DRM war, however, is very much unwon. What should be as simple* as "provide authentication credentials, receive video stream" has been complicated to permit the provider to distinguish between viewing on set-top boxen, "normal" PCs, and mobile devices, so they can charge different amounts and/or have different content available.
*This is particularly true for subscription-based (watch any content number of times while your subscription is valid) or library-based (watch particular content any number of times as long as it's in your library) services -- any service letting you pay once to view once, and pay again if you want to view again, gets a little more complicated, to handle connection droppage, etc., but still doesn't need the DRM they actually use. Since all the real services I have any interest in are in the first two classes, this is an academic point to me, but I don't know if other streaming services may be literally pay-per-view.
We won the downloadable music DRM wars, you mean. (And possibly the downloadable video one, as well; I'm not involved, so I don't know the state of that.)
The streaming video DRM war, however, is very much unwon. What should be as simple* as "provide authentication credentials, receive video stream" has been complicated to permit the provider to distinguish between viewing on set-top boxen, "normal" PCs, and mobile devices, so they can charge different amounts and/or have different content available.
*This is particularly true for subscription-based (watch any content number of times while your subscription is valid) or library-based (watch particular content any number of times as long as it's in your library) services -- any service letting you pay once to view once, and pay again if you want to view again, gets a little more complicated, to handle connection droppage, etc., but still doesn't need the DRM they actually use. Since all the real services I have any interest in are in the first two classes, this is an academic point to me, but I don't know if other streaming services may be literally pay-per-view.
It's a solution to the classic problem of how to fit a phone in the pocket of jeans, which are tightly conformed to one's curved thigh.
Now it's not as good a solution as ditching the tight jeans, but it is a solution.
Yeah, sure, because the first thing the cops check for when they're told 5523 south 43rd street is selling drugs is whether they've got wireless or not.
If you're lucky, they bothered to double check the address so they don't kick in your door at 5532 with a no-knock warrant, unannounced, guns blazing.
Perhaps I'm being silly, but I'd have thought people who wanted to engage in an ongoing discussion of the Fifth Amendment with Bennet Haselton could be reading, and responding to, Bennet Haselton's blog. Why is it on/.?
Anyway, I found this bit amusing:
But it means that if this is the primary argument in favor of the Fifth Amendment, then what the people making this argument are really saying, is that the whole system is broken.
Because it would really be odd if a whole bunch of people, from the Founders who wrote the amendment to OWS, were saying "the whole system is broken"? Even though they say/said that in far more direct ways all the time?
A gasoline powered horse might well fit the bill for the kinds of asymmetrical warfare situations US troops are now facing, where they have a fortified forward base that's practically impenetrable to the insurgent enemy, but are forced to patrol outside that base. The mystery to me is, why not some kind of autonomous wheeled vehicle? You could put the wheels on legs to give it the ability to move its wheels over obstacles.
Yeah, it all starts with cute blue autonomous leg/wheeled vehicles: simple tanks with a primitive AI, what could go wrong.
Next thing you know, they're developing a taste for natural lubricants, reading Flowers for Algernon, and having philosophical debates about life, death, and self-sacrifice. And think long and hard if you consider using them on the same op with vespiform UAVs -- who'd have thought robots would take up the concept of "natural enemy", but that's a darwinian struggle that'll wreck your town right up.
Shielding makes it impractical, no matter how small a reactor can be -- stopping 50% of rays/particles of a given type and energy takes a certain thickness of shielding. So basically, supposing that the intensity of radiation scales linearly with power, the shielding required to reduce that to a constant level scales with ln(power), so half the power doesn't let you use half the shielding.
Ignoring shielding (for the sake of discussion)... it might be possible, but it's still a very difficult problem; the reactor core itself doesn't scale down very well either, and to convert the resulting heat (say, ~200 kW) into mechanical energy (say, ~40kW, enough for a car of modest performance), you still need a heat engine which will unsurprisingly be roughly the size of a 40kW heat engine already used -- so you don't even have the entire engine compartment to shove your reactor in. At best, you're taking a large car, shoving a economy car engine in it, and trying to cram a nuclear reactor into the space left over. Good luck with that.
I really wish people could understand that. the small nuclear reactors could power a laptop or two for 30 years but could never produce enough electricity fast enough to run a clothes dryer for one run.
You know, people would be more likely to understand that if we could stop this business of calling RTGs "reactors". The concept of a "reactor" (whether chemical, biological, or nuclear) is usually that it provides some form of support for a reaction to take place which otherwise would not take place, or would only take place in a different, less useful/safe/something way.
Radioactive decay is not in any meaningful sense a "reaction", and would be happening to the Pu (or other "fuel", if you're using something different) whether or not it's in the RTG, at essentially the same rate, generating the same amount of heat. The only thing the RTG does is feed the decay heat through a heat engine (typically a Seebeck device, but there's some work using a Stirling engine), to extract some work from the heat flow -- no reaction, so it's no reactor.
Ordinarily, I'd call such a distinction as this useless pedantry, and not engage in it, but you're correct that there's a problem with people being ignorant about RTGs and thinking they have capabilities they don't -- and since I'm convinced the general habit of calling RTGs "nuclear reactors" contributes to this, I think it's a distinction worth making.
(...) fail2ban and such scripts are ineffective, because the attempts are so low-frequency that it's practically impossible to distinguish them from users fumbling their passwords.
I'm sorry but that's just nonsense. Ordinary users don't often fsck up their login 3 or 4 times in a row. The boxes in the HM cloud will and so the operators will fairly quickly run out of usable host for their brute force attack. How's that ineffective?
OK, in fairness, "practically impossible" was way too strong a wording -- calling it "nonsense" is exactly right. What I should have said is that the commonly deployed algorithms can't be made to reliably distinguish them by simply tweaking the parameters (time to remember, and allowed number of fails in that time). Better algorithms absolutely could block these, eventually, with no risk of bothering legitimate users. Specifically: distinguish between legitimate usernames (or conceivably-fumbled usernames) and names the botnet is guessing -- although if you have a username matching a known botnet guess (inevitable for e.g. root), deal with that accordingly. Instead of dropping further attempts by every known botnet member, let them proceed far enough to log what usernames they're trying now, and add those to the list we're watching out for...
But the botnet being discussed doesn't let one bot "fsck up their login 3 or 4 times in a row" -- they do a round-robin thing so you won't see the same one again for quite a while, and that one won't be trying for the same user account. Even with better algorithms, the risk is that, if you have weak enough passwords, a few thousand machines each trying once or twice could get one of them a hit first- or second- try by that specific bot -- so if you manage to ban them on the third fail, there's a non-negligible chance of them owning an account. IIRC fail2ban does allow to (but by default doesn't) join a distributed detection network; in combination with better algorithms as discussed above, this sort of distributed approach will let you do better.
Of course, the best answer is "don't permit weak passwords" -- either by disallowing passwords, or by enforcing realistic password strength requirements... but you're very correct that it's possible to do some automated detection and blocking. Mea culpa.
low-intensity bruteforcing is not dangerous - therefore it does not matter that fail2ban doesn't help. Basically, all fail2ban does is turning a fast bruteforce attack into a low-intensity one anyway.
Yes, of course -- what's dangerous is not the low intensity attack itself, but that they command enough bots to make low-intensity attacks have a reasonable chance of success against lousy passwords. And that's only dangerous in combination with the fact that you're permitting users to have lousy passwords.
Tricky passwords is enough - they can't guess them in a lifetime with a low-intensity attack.
Amen, brother. That's absolutely enough -- if you enforce it.
The main reason I suggested key-based auth first is because some fools' idea of "make sure users use strong passwords" is to force users to change their passwords frequently, and tell them to use strong passwords (e.g. not derived from a single english word), and maybe enforce silly requirements such as "must have at least one letter and one numeral"; this inevitably results in "password1" the first month, "password2" the next month, and so on.
My experience was a while ago; I'm not sure what all's been deprecated in newer kernels, as I've been using framebuffer consoles for years. For a while, I found the framebuffer console unbearably slow, but after I discovered how to enable acceleration in vesafb, it wasn't real bad.
But AFAIK, the recipe is still to somehow boot your system up in VGA text mode, any text mode (I'd have said "vga=normal" was a good start... that deprecation message is new to me, but google suggests using "GRUB_GFXPAYLOAD_LINUX=text", so maybe search for that), then use svgatextmode to twiddle stuff. If your initial text mode has the right number of columns, and a suitable number of lines, you don't even need any of the drivers to work -- you can just change it from 16-line font (for 80x25) to an 8-line font (you get 80x50), without changing any timing info. There's also a limited selection of somewhat-extended modes that will work on any VGA-compatible card, by using the various graphics mode clocks in text mode.
More advanced modes (like my 160x100) require support for setting arbitrary dot-clocks instead of using the predefined ones, and that will require identifying a driver that works, then possibly some PCI ID hackery to make it use that driver. But if all you want is 80x50, that part's unneeded.
This is about the low-intensity password brute-forcing via ssh that's been going on for years --
the only difference between this and any other password brute-forcing via ssh is that fail2ban and such scripts are ineffective, because the attempts are so low-frequency that it's practically impossible to distinguish them from users fumbling their passwords.
The simple solution is to disable password authentication for all users, and make them use keys -- this renders you 100% safe from this botnet. If that's infeasible, be damn sure you've disabled password authentication for root (i.e. "PermitRootLogin no" or "PermitRootLogin without-password" if you still want key-based root logins). If you do allow password logins for any or all users, enforce strong password requirements.
And when you start wanting peculiar stuff (like a non 80x25 textmode / framebuffer, or triple displays), you are shit outta luck with nvidia drivers/cards; nouveau at least handles the framebuffer thing decently well.
Simply not true WRT non-80x25. I had a GeForce FX something-or-other in my desktop (back when such a beast was in production), and had no trouble getting a 160x100 textmode, though in practice I used 136x85 most of the time. (I found 136x85 comfortable on my 19" monitor; the main purpose of 160x100 was to show off with mplayer+aalib.) The textmode coexisted with nvidia's binary drivers for X, no problem.
I used svgatextmode with the Riva TNT2 driver (for young
whippersnappers, the Riva series was the predecessor to the GeForce series, and for some operations such as needed for establishing textmodes they are compatible); svgatextmode is no longer maintained, so I had to patch svgatextmode's PCI ID list for my card to be recognized as TNT2 compatible, but then it worked just fine.
(Yes, I'm aware that the preceding sentence is a perfect illustration of why "the year of Linux on the desktop" keeps being prophesied and never happens. But I got my 160x100 text mode on my desktop, and that's all I can be bothered to care about!)
Slashdot Mirror
The point of the patent sytem is not to make people pay royalties, but to create an incentive for inventors -- if the inventor gets neither the royalties (by licensing the patent) nor the monopoly (by not licensing the patent), there's no incentive, no matter whether those using the patented invention make royalty payments to some other entity or not.
If you've already taken away the inventor's incentive, what possible reason is there for the government's licensing fee?
It's the genetic equivalent of adding the Euro sign into your system fonts.
That's actually a remarkably accurate analogy, if you add the Euro sign at ascii position 0x09 (aka ^I, aka HT) and modify your software (e.g. C compiler) to treat tabs as a normal character instead of whitespace.
Anybody not agreeing with the Ruling Class is now "Tea Party", huh?
That would suggest that Ubuntu/Canonical is the ruling class in the Linux world, which is certainly not true.
In Mark Shutupworth's mind it is!
Oops, should've used preview...
Last paragraph, take 2:
In the end, though, the big issue, and the reason you don't see the |tee fifo| and <fifo idiom used very often, much less foo >fifo1& bar >fifo2& baz fifo1 fifo2, is that UNIX is command-line based, and arbitrary graphs are just plain hard to represent well in a single command line. Naming nodes (i.e. FIFOs) and referring to them later by name does yield a mathematically general representation, but it's nowhere near as intuitive to use as the simple anonymous pipes in foo|bar|more, so it's doomed to neglect.
Except UNIX has a single flow control model for those pipelines,
Yeah.
has difficulty forking data to two places except in very simple cases (tee)
Eh, are you forgetting named pipes, aka fifos? because (foo | tee myfifo | bar)& baz <myfifo and more elaborate versions of that theme seem to be able to handle any complex case I can think of in terms of the simple case.
and cannot join [two] processes together to feed a third.
I'm not quite sure what you mean by this -- if you mean to merge two outputs into the single input of the third process, this is again simple with fifos. (Of course, each of the first two processes' buffering behavior contributes to the order or chaos resulting -- but if everything is buffering i/o a line at a time, and a line is logically a complete packet, it pretty much works.)
If, OTOH, you mean to have a process with two separate inputs (e.g. one for a video stream, one for subtitles to be superimposed on it), this is possible in the UNIX model (simply assign file descriptors higher than 2 in the same way stdin, stdout, and stderr are redirected), and at least some ksh derivatives do support redirecting arbitrary file descriptors; however, few if any of the ordinary UNIX utilities do anything of this sort. In part, this is because there are few uses (that I can think of) for this without enhancing the flow control model or allowing data types other than text; in part, it's because stdin, stdout, and stderr work because they are standardized, therefore there's no preexisting uniform mechanism for e.g. a filter with a variadic inputs (in other words, for each such multi-input program, the user would be responsible to learn what file descriptors correspond to what inputs and outputs, what switches (if any) control those assignments, and keep all this info in their head).
(However, many UNIX utilities do accept multiple filenames as arguments, and these files can in many cases be fifos, so even though it strays from the pure "shell redirects everything" model, you can still do that.)
In the end, though, the big issue, and the reason you don't see the |tee fifo| and <fifo idiom used very often, much less foo >fifo1& bar >fifo2& baz fifo1 fifo2, is that UNIX is command-line based, and arbitrary graphs are just plain hard to represent well in a single command line. Naming nodes (i.e. FIFOs) and referring to them later by name does yield a mathematically general representation, but it's nowhere near as intuitive to use as the simple anonymous pipes in foo|bar|more, so it's doomed to neglect.
Instead, download MythTV, set it to automatically record your favorite actors and shows, and watch pretty much whatever you want, whenever you want, at no cost.
As long as "whatever you want" doesn't include cable shows, overseas shows, or (depending where you live) shows on lesser networks such as the CW that don't have an affiliate in every small city, then sure, PC-based DVR is awesome and free.
Anyway, if OTA programming you can receive in your location with an antenna at your location is all you want to watch, I don't see how you're any more or less of a "free-loading scumbag" to watch it sans ads with a DVR rig (PC-based or not) or to watch it sans ads by downloading a pirated copy. One is legal, the other is illegal, but they have exactly the same effect on the content producer's bottom line.
I didn't even click on the link and knew it was some fag linking xkcd.
Well, it is a link that leads to xkcd.com, so it's not exactly difficult to figure out that that's where the link leads.
Yeah, but unlike GP, you couldn't deduce that link was posted by a cigarette!
Android/Chrome here, and there's actually a built-in checkbox to send a desktop UA. Unfortunately (and somewhat incredibly), there's no way to default this checkbox "on" (i.e. you have to click it once in each new tab, to make that tab send a desktop UA), and when you toggle it, it goes back to the last address you typed in the URL field and reloads that, presumably so as to avoid any redirects (e.g. www.example.com -> m.example.com), but also avoiding any deliberate clicks you've made.
When posting the above, I got halfway here before I rembembered to click it, so rather than backtracking, I thought "WTH, let's try /.'s mobile interface again" (tried it for a week back when it was new; didn't like it) -- turns out, there's still no preview button (?!), and it requires manual <p> insertion (instead of line-feeds) to make your comment not one giant paragraph. (Should've known better, yeah...)
So I'm back to clicking that damn checkbox every time and cursing the name of Google.
I really need to get back to tinkering with Arch on here -- I bought a TF700 with that in mind, but got stuck on Android for a while when nobody had dual-boot working with a 4.2-compatible kernel. Once I get Arch back up, I'll be able to go back to normal, desktop browsers. (The mobile versions of both Firefox and Chrome both have insane amounts of deliberate suck that cannot be disabled, no matter how big a screen my "tablet" has, or how many keyboards and mice I have temporarily or semipermanently connected -- I'm running Android, so I must be treated to behavior that's at best arguably suited to a 3.5" keyboardless phone.) Not to whine, but it shouldn't be this much hassle to get an ARM-powered laptop running a normalish GNU/Linux distro -- but maybe I just got spoiled with my N810.
/rant
We won the downloadable music DRM wars, you mean. (And possibly the downloadable video one, as well; I'm not involved, so I don't know the state of that.)
The streaming video DRM war, however, is very much unwon. What should be as simple* as "provide authentication credentials, receive video stream" has been complicated to permit the provider to distinguish between viewing on set-top boxen, "normal" PCs, and mobile devices, so they can charge different amounts and/or have different content available.
*This is particularly true for subscription-based (watch any content number of times while your subscription is valid) or library-based (watch particular content any number of times as long as it's in your library) services -- any service letting you pay once to view once, and pay again if you want to view again, gets a little more complicated, to handle connection droppage, etc., but still doesn't need the DRM they actually use. Since all the real services I have any interest in are in the first two classes, this is an academic point to me, but I don't know if other streaming services may be literally pay-per-view.
(This just in, /.'s mobile interface sucks.)
We won the downloadable music DRM wars, you mean. (And possibly the downloadable video one, as well; I'm not involved, so I don't know the state of that.) The streaming video DRM war, however, is very much unwon. What should be as simple* as "provide authentication credentials, receive video stream" has been complicated to permit the provider to distinguish between viewing on set-top boxen, "normal" PCs, and mobile devices, so they can charge different amounts and/or have different content available. *This is particularly true for subscription-based (watch any content number of times while your subscription is valid) or library-based (watch particular content any number of times as long as it's in your library) services -- any service letting you pay once to view once, and pay again if you want to view again, gets a little more complicated, to handle connection droppage, etc., but still doesn't need the DRM they actually use. Since all the real services I have any interest in are in the first two classes, this is an academic point to me, but I don't know if other streaming services may be literally pay-per-view.
I strongly suspect you missed some sarcasm in there. (Poe's Law being what it is, I can't be sure...)
If not, then you've almost certainly been trolled.
Either way... YHL. HAND.
It's a solution to the classic problem of how to fit a phone in the pocket of jeans, which are tightly conformed to one's curved thigh. Now it's not as good a solution as ditching the tight jeans, but it is a solution.
Yeah, sure, because the first thing the cops check for when they're told 5523 south 43rd street is selling drugs is whether they've got wireless or not.
If you're lucky, they bothered to double check the address so they don't kick in your door at 5532 with a no-knock warrant, unannounced, guns blazing.
5532 south 43rd, isn't that Harry Buttle's place?
Perhaps I'm being silly, but I'd have thought people who wanted to engage in an ongoing discussion of the Fifth Amendment with Bennet Haselton could be reading, and responding to, Bennet Haselton's blog. Why is it on /.?
Anyway, I found this bit amusing:
But it means that if this is the primary argument in favor of the Fifth Amendment, then what the people making this argument are really saying, is that the whole system is broken.
Because it would really be odd if a whole bunch of people, from the Founders who wrote the amendment to OWS, were saying "the whole system is broken"? Even though they say/said that in far more direct ways all the time?
A gasoline powered horse might well fit the bill for the kinds of asymmetrical warfare situations US troops are now facing, where they have a fortified forward base that's practically impenetrable to the insurgent enemy, but are forced to patrol outside that base. The mystery to me is, why not some kind of autonomous wheeled vehicle? You could put the wheels on legs to give it the ability to move its wheels over obstacles.
Yeah, it all starts with cute blue autonomous leg/wheeled vehicles: simple tanks with a primitive AI, what could go wrong. Next thing you know, they're developing a taste for natural lubricants, reading Flowers for Algernon, and having philosophical debates about life, death, and self-sacrifice. And think long and hard if you consider using them on the same op with vespiform UAVs -- who'd have thought robots would take up the concept of "natural enemy", but that's a darwinian struggle that'll wreck your town right up.
Shielding makes it impractical, no matter how small a reactor can be -- stopping 50% of rays/particles of a given type and energy takes a certain thickness of shielding. So basically, supposing that the intensity of radiation scales linearly with power, the shielding required to reduce that to a constant level scales with ln(power), so half the power doesn't let you use half the shielding. Ignoring shielding (for the sake of discussion)... it might be possible, but it's still a very difficult problem; the reactor core itself doesn't scale down very well either, and to convert the resulting heat (say, ~200 kW) into mechanical energy (say, ~40kW, enough for a car of modest performance), you still need a heat engine which will unsurprisingly be roughly the size of a 40kW heat engine already used -- so you don't even have the entire engine compartment to shove your reactor in. At best, you're taking a large car, shoving a economy car engine in it, and trying to cram a nuclear reactor into the space left over. Good luck with that.
I really wish people could understand that. the small nuclear reactors could power a laptop or two for 30 years but could never produce enough electricity fast enough to run a clothes dryer for one run.
You know, people would be more likely to understand that if we could stop this business of calling RTGs "reactors". The concept of a "reactor" (whether chemical, biological, or nuclear) is usually that it provides some form of support for a reaction to take place which otherwise would not take place, or would only take place in a different, less useful/safe/something way.
Radioactive decay is not in any meaningful sense a "reaction", and would be happening to the Pu (or other "fuel", if you're using something different) whether or not it's in the RTG, at essentially the same rate, generating the same amount of heat. The only thing the RTG does is feed the decay heat through a heat engine (typically a Seebeck device, but there's some work using a Stirling engine), to extract some work from the heat flow -- no reaction, so it's no reactor.
Ordinarily, I'd call such a distinction as this useless pedantry, and not engage in it, but you're correct that there's a problem with people being ignorant about RTGs and thinking they have capabilities they don't -- and since I'm convinced the general habit of calling RTGs "nuclear reactors" contributes to this, I think it's a distinction worth making.
(...) fail2ban and such scripts are ineffective, because the attempts are so low-frequency that it's practically impossible to distinguish them from users fumbling their passwords.
I'm sorry but that's just nonsense. Ordinary users don't often fsck up their login 3 or 4 times in a row. The boxes in the HM cloud will and so the operators will fairly quickly run out of usable host for their brute force attack. How's that ineffective?
OK, in fairness, "practically impossible" was way too strong a wording -- calling it "nonsense" is exactly right. What I should have said is that the commonly deployed algorithms can't be made to reliably distinguish them by simply tweaking the parameters (time to remember, and allowed number of fails in that time). Better algorithms absolutely could block these, eventually, with no risk of bothering legitimate users. Specifically: distinguish between legitimate usernames (or conceivably-fumbled usernames) and names the botnet is guessing -- although if you have a username matching a known botnet guess (inevitable for e.g. root), deal with that accordingly. Instead of dropping further attempts by every known botnet member, let them proceed far enough to log what usernames they're trying now, and add those to the list we're watching out for...
But the botnet being discussed doesn't let one bot "fsck up their login 3 or 4 times in a row" -- they do a round-robin thing so you won't see the same one again for quite a while, and that one won't be trying for the same user account. Even with better algorithms, the risk is that, if you have weak enough passwords, a few thousand machines each trying once or twice could get one of them a hit first- or second- try by that specific bot -- so if you manage to ban them on the third fail, there's a non-negligible chance of them owning an account. IIRC fail2ban does allow to (but by default doesn't) join a distributed detection network; in combination with better algorithms as discussed above, this sort of distributed approach will let you do better.
Of course, the best answer is "don't permit weak passwords" -- either by disallowing passwords, or by enforcing realistic password strength requirements... but you're very correct that it's possible to do some automated detection and blocking. Mea culpa.
low-intensity bruteforcing is not dangerous - therefore it does not matter that fail2ban doesn't help. Basically, all fail2ban does is turning a fast bruteforce attack into a low-intensity one anyway.
Yes, of course -- what's dangerous is not the low intensity attack itself, but that they command enough bots to make low-intensity attacks have a reasonable chance of success against lousy passwords. And that's only dangerous in combination with the fact that you're permitting users to have lousy passwords.
Tricky passwords is enough - they can't guess them in a lifetime with a low-intensity attack.
Amen, brother. That's absolutely enough -- if you enforce it.
The main reason I suggested key-based auth first is because some fools' idea of "make sure users use strong passwords" is to force users to change their passwords frequently, and tell them to use strong passwords (e.g. not derived from a single english word), and maybe enforce silly requirements such as "must have at least one letter and one numeral"; this inevitably results in "password1" the first month, "password2" the next month, and so on.
My experience was a while ago; I'm not sure what all's been deprecated in newer kernels, as I've been using framebuffer consoles for years. For a while, I found the framebuffer console unbearably slow, but after I discovered how to enable acceleration in vesafb, it wasn't real bad.
But AFAIK, the recipe is still to somehow boot your system up in VGA text mode, any text mode (I'd have said "vga=normal" was a good start... that deprecation message is new to me, but google suggests using "GRUB_GFXPAYLOAD_LINUX=text", so maybe search for that), then use svgatextmode to twiddle stuff. If your initial text mode has the right number of columns, and a suitable number of lines, you don't even need any of the drivers to work -- you can just change it from 16-line font (for 80x25) to an 8-line font (you get 80x50), without changing any timing info. There's also a limited selection of somewhat-extended modes that will work on any VGA-compatible card, by using the various graphics mode clocks in text mode.
More advanced modes (like my 160x100) require support for setting arbitrary dot-clocks instead of using the predefined ones, and that will require identifying a driver that works, then possibly some PCI ID hackery to make it use that driver. But if all you want is 80x50, that part's unneeded.
This is about the low-intensity password brute-forcing via ssh that's been going on for years -- the only difference between this and any other password brute-forcing via ssh is that fail2ban and such scripts are ineffective, because the attempts are so low-frequency that it's practically impossible to distinguish them from users fumbling their passwords.
The simple solution is to disable password authentication for all users, and make them use keys -- this renders you 100% safe from this botnet. If that's infeasible, be damn sure you've disabled password authentication for root (i.e. "PermitRootLogin no" or "PermitRootLogin without-password" if you still want key-based root logins). If you do allow password logins for any or all users, enforce strong password requirements.
And when you start wanting peculiar stuff (like a non 80x25 textmode / framebuffer, or triple displays), you are shit outta luck with nvidia drivers/cards; nouveau at least handles the framebuffer thing decently well.
Simply not true WRT non-80x25. I had a GeForce FX something-or-other in my desktop (back when such a beast was in production), and had no trouble getting a 160x100 textmode, though in practice I used 136x85 most of the time. (I found 136x85 comfortable on my 19" monitor; the main purpose of 160x100 was to show off with mplayer+aalib.) The textmode coexisted with nvidia's binary drivers for X, no problem.
I used svgatextmode with the Riva TNT2 driver (for young whippersnappers, the Riva series was the predecessor to the GeForce series, and for some operations such as needed for establishing textmodes they are compatible); svgatextmode is no longer maintained, so I had to patch svgatextmode's PCI ID list for my card to be recognized as TNT2 compatible, but then it worked just fine.
(Yes, I'm aware that the preceding sentence is a perfect illustration of why "the year of Linux on the desktop" keeps being prophesied and never happens. But I got my 160x100 text mode on my desktop, and that's all I can be bothered to care about!)
using the thermal deferential between the fire and water
News for nerds, homophones that matter?