There's an assumption here that the key fob only has a range of 30cm - are we sure that's the case? I don't have one of these specific systems, but I do have a remote fob for my car and it's good for tens of meters (I've not tried to establish the max range), which is mostly intended for stuff like turning on the AC to start to cool a hot car. Perhaps the system works by having the same type of fob with the added functionality of a receiver - when it receives the weak signal from the car, perhaps it just sends the regular high powered "open door" signal in response. You might still need a high powered receiver to pick up and boost the fob signal if it's far away, but it does resolve the 30cm:30cm problem.

The sample posted earlier was the only one I'd ever seen, so I was quite surprised about the scale of the problem. Having it spammed into old threads would explain that though, which is possibly one reason why Slashdot archives older discussions. You're right about the pain of having stuff dropped into a submission queue though, and simply blocking common spam terms like "viagra" and the like is obviously going to give many false positives on a site that might discuss them, and will probably have them used in humourous comments elsewhere.

Getting back to the regexps, it's hard to say what (if anything) would work for Pipedot without a good overview of the crap being submitted, but one general technique that does seem like it would work well for typical forum spam (including your example) is to trigger off excessive use of certain punctuation marks, particularly in subjects - commas and hyphens seem well liked by many forum spammers; the one in your example put four in there. Ideally you'd probably also want to have a requirement that multiple rules match before a post goes into the moderation queue, or even a basic scoring system like SpamAssassin et al use, but based on the comments above that's probably overkill - at least at present. Ultimately though it's still an arms race, and the spammers will adapt as soon as they realise they are being blocked; sometimes you just have to go for the easy stuff and accept that the rest might need manual handling later.

Or the team could be more proactive on the backend. Many of the bots (or low-rent workers in 3rd world sweatshops, it's hard to tell these days) that stuff forums and submission queues seem to follow a fairly standard template so a few well crafted regexp's combined with a tool like Fail2Ban feeding the IP blacklist might nail a lot of the low hanging fruit before anyone even gets to see it.

I think it's going to end up in the same situation, or verty similar situation, to firearms since they have the same combination of being extremely useful tools for some situations yet with a massive potential for abuse. Perhaps the pro-BitTorrent mantra could draw on that too: "BitTorrent doesn't infringe copyright, people do".

What *is* the going rate for The One Ring these days? ;)

That air and lint has to be worth something, right?

I'll second the vote for Moon+ Reader here. I registered and use the Pro version on my Transformer and find it consistently gives the best results, is very stable, and has good performance - with the exception of handling PDFs which could use some work. For that I tend to use EBookDroid, which also has a great 2-up display mode that I use for a couple of PDF photography magazines that have a lot of image heavy double page spreads.

Not having room due to a limited word count shouldn't be a problem for a competent writer; you don't have to publish test methodologies and reams of results in that case, just summarise your findings. He does say that LXDE is insanely fast, before launching into how mundane it is and that he can't think of anything much to say. A far more useful article would have been to comment on about how much quicker (or not) it felt when trying to run a remote desktop compared with KDE/Gnome/Windows/OSX, how the simple interface and lack of visual FX might be contributing to that, point out the inconsistencies in the interface, and opine about why/when you might want to chose LXDE over other distros.

As stands, it smacks of an article that was phoned in just to meet an arbitrary word count and get paid that probably would have been better left unpublished by the site's editor.

Yeah, the reviewer completely missed the point of LXDE. Lightweight desktops are aimed at people that just want the UI to get the hell out of the way and let them get on with doing actual work without any distractions or bogging down systems with limited resources (e.g. a lightweight CPU, low memory, or limited bandwidth for remote GUI desktops), LXDE does that pretty much perfectly. I prefer KDE for my main *NIX desktop, albeit with most of the distracting bling switched off, but even with a high bandwidth connection if I want a remote GUI desktop I tend to switch to LXDE, XFCE or something similar.

Instead of writing about the lack of any bling, the article should have focussed on benchmarking how much better it performs vs. the likes of KDE and Gnome with limited resources available, the benefits provided by lack of UI distractions, what has been removed to facilitate that, and maybe even how you can possibly add back in those bits of bling that you really can't do without. What a waste of bits...

Similar here, although even without the keyboard I tend to surf the web, read email etc. in landscape mode. I generally only use portrait mode when I'm reading an eBook (for which I always remove the keyboard and use portrait mode) or for some web sites, or even specific articles, that I think work better that way around. Probably that's just pre-conditioning on my part and that of web site designers; we're still used to the landscape orientation of desktop monitor being the norm, even though some recent web stats imply that most browsing for some sites is now done via phones and tablets.

I see a few suggestions for solar, and this is good; you are at high altitude so the increased efficiency might offset some of the days where the weather is bad, but I can't help but feel that suitably efficient panels are bulky, fragile and expensive. I've not idea if this will work in your specific region, but it might be worth considering other forms of natural energy, specifically wind and water, as a power source. You ought to be able to construct a windmill and/or watermill using locally sourced materials - wood, mostly - so all you would need to take would be some power sockets, wire and a small motor/transformer to generate the power. A quick Google turns up a bunch of links, but this one should give you an idea of what might be possible, and it's also the kind of project that could get the locals involved and take on a life of its own over the course of the stay.

24 hours, perhaps? Actually probably a few days since there are probably readers who don't check Pipedot every day.

I'm a little surprised they didn't just geolocate the IPs of the posters and produced a graph from that, although it could be interesting to do compare the results of that with the results from the poll.

Pretty much echoes my sentiments regarding SysVinit. It gets the job done with minimal resources, but it's not really appropriate for modern systems where a parallel and dependency driven init process is a major user requirement and resources are no longer an issue - especially on desktop and mobile devices where the user would like as near to instant on as possible. Despite that I find SystemD does what it is supposed to without too much fuss, and is in many ways more capable than sysvinit, I also think it's a bloated mess that was badly designed from the start, and when it comes unstuck fixing it is an absolute nightmare. Don't even get me started on the whole DBus integration/requirement thing; that sounds more like something Microsoft would have cooked up for Windows than the core principles of UNIX, and is one of the main reasons that I'm taking a good look at migrating as many of our Linux servers over to BSD as possible when they are next due for a refresh.

PID1 needs to just do the essentials and be a minimal piece of code that is pretty much as close to "hello world" as you can get to avoid complications and failures, everything else should either be an optional SystemD module or an external program depending on the the user's preference. Want SystemD to handle your logging, fine, tell it to load that module and off you go. Want to run a proper daemon that can listen for remote log entries too, then disable the SystemD module and use RSyslog or whatever you prefer. Some functions of SystemD are already modular, but that needs to go a lot further in my view, and requiring stuff like DBUS integration right there in PID1 is just asking for all sorts of stability problems, but it into a module, then at least there's a chance the system might be able to recover without a kernel panic.

Pretty sure it's going to vary from person to person, but I have a LOT of digital media, mostly from my photography and videography, and to me archiving is still online, just on the big slow NAS (relatively speaking, it's actually pretty snappy) instead of the fast DAS, whereas "backed" up is a cold, offline storage medium, one copy of which is held off-site. The latter for me are external USB3 HDDs which get replaced every few years, because that's still cheaper than tape, faster than tape, and ensures that I have to re-verify (and occassionally prune) the data when I move it to a new set of drives (I have a few extra steps in the process to avoid fat-finger problems and so on than just copying the data over, and so far haven't lost a single file).

Having used commercial software on Linux in the manufacturing sector, support is usually only provided for a few main distros anyway (Debian, Red Hat and SuSE in my case). If you can get the binary to run on another distro, then that's great, but you are not going to get anything close to the same level of support as the officially sanctioned distros. For most applications I actually don't see that as a major problem, although RMS would certainly have something to say about the restriction of choice; it's still Linux, and in a commercial setting you are probably choosing the best OS/distro for your required apps anyway, rather than the other way around.<br><br>

Another problem was the issue of libraries, particularly when they were more obscure on one distro but bundled with another. A poke around in the dependencies for the various packages revealled that the typical solution here was either to statically link any such libraries across the board, or in a few cases to do so selectively from distro to distro, dynamically linking to the distro provided versions where available and statically linking the rest. Worst case scenario would be to just statically link the entire lot, which is an approach I've seen used for several Linux games - commercial or otherwise.<br><br>

So, it's not as if the problems don't have solutions, although they are not necessarily ideal, which leave me thinking it's more to do with the low return on the time and effort required. Unless you are working off the back of one of the major Linux desktop migrations that pop-up from time to time and making the binaries available to all, you have a much smaller userbase, split across multiple distros that are potentially different enough to be treated like different OSs from a compilation and support perspective. Each distro you support gets you more users, but adds to the cost of developing, compiling and testing the code, plus supporting it when you are done, and for many apps, particularly the more complication ones the numbers almost certainly just don't add up. So perhaps the real question is "what can the Linux community do to make the numbers add up?"

It's not that Linux is lacking software, quite the opposite in fact, it's lacking viable alternatives to commercial software for which there is currently nothing that can come close in terms of capabilities and/or is as convenient to use for which the vendor hasn't released a native version, or simply won't do so.

That would be my view too, but there would probably still be a problem with consistency. The icons, which looked great BTW, all had a consistent appearance and size which is obviously not going to be the case with images, and trying to find appropriate images that can be cropped and scaled down to the same size as the icons is likely to be even harder than finding an appropriate icon. If going with images then we're just going to have to accept some variation in appearance. Then again, maybe that's not the real problem, but rather that the topics that stories are grouped into isn't a good enough or broad enough match for the range of stories being posted - or there just needs to be a generic icon for when all else fails.

Never saw any need for it. Distracting, usually at least partially (and more often almost totally) obscured. I used to use a simple tiling pattern that sort of resembled leather, but in the end just switched to a plain greyish-blue that I switch to a neutral ~18% grey when I'm editing images or videos.

Or just don't take the devices in the first place, although having access to what could be critical information such as weather forecasts and the ability to contact emergency services (not that you should *ever* rely on just a mobile phone for that) might be an issue. It's also sometimes useful to be able to look up information on flora, fauna and geological features that you chance upon that you are curious about for some reason. The flipside is that depending on the location you might not be alone as there are various communal facilities at campsites etc. Even though you might have the disciple to leave your stuff at home or switched off, it doesn't follow that others do, so you would still have other people surfing on their tablets and nattering on their phones while you are trying to be one with nature.

So yes, having the option is great, but that also needs to be backed up with respect for the wishes of others present that might not want to see/hear it and a suitable amount of discretion over when, where and how the option is used.

Why is it easier to trust Google?

Perhaps because they own the entire ecosystem and it's in their best interests to protect your data because it is also *their* data? Also, despite all the Google-hate, they do generally do a lot more stuff that is good for the 'net at large than the other companies on the list, so even if you don't trust them outright there is probably at least some feel-good factor at play.

I think ISC is actually only ending development of BIND 10, and it is this tree that is being renamed to Bundy and transferred to GitHub. As ISC notes in the article, BIND 9 is a separate project for which there is no mention of development ending, so I assume this to mean they will continue to develop BIND 9.

It's long overdue for an independant audit, IMHO, but the OpenSSL code is now getting a review and code clean up by the OpenBSD team and they certainly know their stuff. Whether the results and reporting on their findings will be as in-depth as the TrueCrypt audit remains to be seen, but it's still infinitely better than nothing. Really this ought to be the kind of the thing that the various FL/OSS projects should be pushing for from their commercial users as well as contributions to the code base itself. No in-house devs to help with contributions to the code, fine, then how about contributing some funds for an independant code audit instead? Help us make your systems more secure!

Selective password changes here too, made much easier by having unique passwords per site already, and increased the password length on a few of them too. Those that use OpenSSL and have data I care about got reset, the rest I just let be for now but will change them if anything unusual happens.

Objects in orbit can also get very warm when in direct sunlight as they can't readily convect the energy gained from the sun away to a vacuum, so you'd also need to convert that heat into a form of radiation that can be disposed of. It's not an insurmountable problem, but I suspect you'd be much better off just by giving a little big more thought to locating data centres on Earth to climes more suited to passive, or at least renewable, temperature control.