Well, I mean, nearly everyone has a phone everywhere. But we *don't* generally walk around with it unlocked and the banking app loaded.
955 posts • joined 4 Nov 2010
Well, I mean, nearly everyone has a phone everywhere. But we *don't* generally walk around with it unlocked and the banking app loaded.
Or compared to:
1) take card from wallet
2) tap card
done. NFC is not particularly secure (though if you're worried you can always buy a lead-lined wallet or whatever), but it sure *is* incredibly convenient. And I dunno about 'the West', but in Canada it's more unusual to find a place which *doesn't* accept contactless payment than one which does, now.
I think the capping is a policy thing, sadly. The Vancouver system is not set up to do it; if you do ten regular journeys in a day you pay for ten regular journeys, even though there's a flat-rate all-day fare that's much cheaper. If you want the all-day fare you have to know about it and specifically load it onto your card before you make a trip. Which is really pretty crappy, and they don't have a good excuse for it, so far as I can tell, especially since by all accounts the system is basically the same as Oyster so it certainly ought to be capable. http://askcompass.ca/?QuestionID=1387 (same applies for day pass).
It's not just third-party software. It's stuff like, well, the kernel. Upstream kernel developers are less and less interested in keeping i686 codepaths working, and they frequently just don't any more.
The last vaguely mainstream 32-bit CPU Intel released was in, I believe, 2006. There were 32-bit Atom CPUs up to 2010, by the looks of things, but those were pretty niche-y and you're probably not going to have an awesome experience running a full-fat modern distro on one of those in any case. Almost any 32-bit x86 system you have, in other words, must be at least 6 years old and is far more likely to be over 10 years old. That's really pretty old.
The weird Atom tablets / convertibles from the last few years have 64-bit CPUs but 32-bit firmwares; they don't actually need 32-bit distributions, it's possible for 64-bit distributions to run on them with a bit of nifty bootloader footwork.
"Ubuntu developers are saying that people with old hardware that they do not wish to upgrade or who cannot afford to upgrade are no longer worthy of consideration."
No, they're saying that they no longer want to consider them, in order to devote their limited resources to 'considering' larger user bases. In an ideal world full of rainbows and unicorns OS distributors would be able to make things work perfectly on all hardware ever. In the real world this is not the case, and deciding what hardware to support to what extent is a constant question of making trade-offs, and people getting all irate and stroppy and insisting on taking those decisions excessively personally ('worthy of consideration'? really?) doesn't really help.
There's *always* still some working example of old hardware somewhere. People have working 8088s and Commodore Pets and lord knows what else. That doesn't oblige all OS vendors to keep supporting them. We (I work on Fedora, which stopped considering i686 a release-blocking arch with Fedora 24) have generally decided there's a point at which supporting old hardware is more trouble than it's worth; this is why we no longer actually work on i386s, or i486s, or (for most distros) i586s. That point is coming up fast for i686.
If there's enough demand for it, there'll be niche distros that support these old systems; heck, you could create one. But the mainstream distros, as the name suggests, are there to support *mainstream* hardware. We have to make cost/benefit decisions at some point.
Wow, an expiry time is a business model now? yeesh.
Er, why would your lesson from the "war on tobacco" - which has been probably the single greatest public health success story of the 20th century - be to fight it?
Heck, you don't even have to believe aspartame is definitely safe for it to be the logical choice. It's simple: we know for a copper-bottomed *fact* (very rare when it comes to nutrition) that sugar is extremely damaging. We don't know for sure that aspartame is. So, go with the aspartame!
That's really all you need. It's not even necessary to note that the balance in the sweetener debate is rather strongly in favour of the 'well, we did a bunch of trials and none of them showed any negative effects except at a level of consumption that in humans would translate to drinking sixty cans of Diet Coke a day forever' side, rather than the 'some nutbag on the internet said it would give me cancer' side...
Why would that mean you couldn't trademark it? There's no rule that trademarks have to be 'original' words, most aren't.
Given that VTL is in the title of the article, and is repeated about two dozen times, I'm gonna go out on a limb and say that's what he was talking about.
"Do people really expect smartwatches to be as ubiquitous as smartphones? No, why would they?"
Well, you rather get the feeling Apple would like them to be, since the Apple Watch seems to have been their big bet to move on from the rapidly-maturing and margin-thinning smartphone market...
I'm not a huge smartwatch fan (I bought a Pebble, it was kind of neat, it stopped working properly, I never felt at all like buying another) but that's just stupid logic. Similarly we all used to have fairly robust cellphones with two week battery lives...because all they could do was make phone calls and send text messages really painfully and maaaybe, if you were lucky, play Snake. There's a small core of people who've decided that's all they want from a cellphone and who still use similar devices, and more power to them. But far far more people use relatively fragile and short-battery-lived modern smartphones, and they don't do this because they're stupid or sheep, they do it because they want to use all the capabilities they get *in exchange* for the relative fragility and short battery life.
Similarly it's stupid to argue that smartwatches have to have the same longevity as regular watches in order for anyone to want them, because if they can provide sufficient useful capabilities in exchange for the complexity and charging, then sensible people will make sensible choices to buy them. The problem so far is that they haven't.
"No authentication was required to communicate with the Bluetooth-enabled device. "Anyone with a Bluetooth-enabled device and software for discovering passwords via multiple variants (brute force) could connect to a road sensor in this way," the Kaspersky team discovered."
So, er, no authentication was required except a password, which is authentication, then?
Yep. In fact it's a very good case for the bookies indeed, because likely lots of people will have bet on one of the teams that people actually thought had a chance in hell of winning, and the bookies get to keep *all* that money. They have to pay out eye catching individual sums to the loonies who bet on Leicester, but since there are probably, like, three people who bet any remotely significant amount on that, they still wind up quids in.
With a system allowing the 'phone home' point for existing hardware to be changed, other people could step in to do so: either as a community effort, or a commercial one. A few hundred thousand (or whatever) people with expensive hardware that suddenly does nothing could be a business opportunity for a savvy person: for $x we'll keep your hardware working for the next X months, or for $x/month we'll keep it working so long as you keep paying and we stay afloat.
If the 'phone home' point is hardwired into the hardware (and that connection is secured), there's nothing anyone besides the original manufacturer can do to offer support for the device even if they wanted to, short of coming up with some way to hack the hardware and convincing users to apply it.
AMD is putting their efforts lately into improving the free driver, which is a *much* better idea. It's not quite up to the performance of the proprietary driver yet, but it's getting there.
I had a look at Slack's terms of service when it started getting popular. Unless they've revised them lately, they reserve the right to look at any of your content at any time, and they also reserve the right to delete all your content irretrievably and without any notification.
Hmm, yep, still there:
"You acknowledge that Slack and its designees shall have the right (but not the obligation) in their sole discretion to pre-screen, refuse, or remove any of Your Data that is available via the Service...We may also review Your Data transmitted through non-public mechanisms (such as private channels within the Service) where we deem appropriate, including for violations of this TOS or in response to a user complaint. Without limiting the foregoing, Slack and its designees shall have the right (but not the obligation) to remove any of Your Data that violates the TOS or is otherwise objectionable."
"You acknowledge, consent and agree that Slack may access, preserve and disclose your account information and Your Data if required to do so by law or in a good faith belief that such access preservation or disclosure is reasonably necessary to: (i) comply with legal process; (ii) enforce the TOS; (iii) respond to claims that any of Your Data violates the rights of third parties; (iv) respond to your requests for customer service; or (v) protect the rights, property or personal safety of Slack, its users and the public."
"We reserve the right to deactivate and delete your account (or the access privileges of any Member) and terminate this TOS at any time for any reason, or no reason, with or without notice."
so...yeah, good luck with putting all your mission-critical data there.
We don't want the same interface on a phone as on a computer, right? So all these 'seamless' systems have to come up with some kind of clever software layer which knows or remembers what kind of layout we want for all sorts of things, and when.
So instead of needing a clever software layer of some kind to share data between devices which have a simple time of deciding what interface they want to show you, you need a clever software layer to decide what interface to show you on top of data it has a simple time accessing.
i.e. it's just a trade-off, and not a very obviously good one, since phone flash is not exactly renowned as the world's safest place to store all your data.
I have a colleague who's still configured to accept UUCP-routed mail...
another one I can think of, John Carmack's .plan file was updated up until 2005: http://www.bluesnews.com/cgi-bin/finger.pl?id=1 . Someone else at id updated theirs in 2007: http://www.bluesnews.com/cgi-bin/finger.pl?id=476 . Sadly seems like you can't connect any more, though. :(
Where do you get this drivel?
"Talia sounds like most millennials, an entitled brat that never worked a day in her life.... "
Er. The entire story is about how she was paid far less than a living wage *for her job*. Which she *worked at*. Do you just take lines out of the cliche book and throw them out there with no thought about their relevance to what actually happened?
"Strangely the net neutrality crowd have gone very quiet", says Andrew, and goes on to extrapolate two paragraphs of bollocks from that. Er, this story broke within the last, what, seven hours? Overnight, in the US? You might want to at least give people a day before making wild inferrals on the sole basis that they didn't say anything yet.
Cableco #1: "...The FCC's thumb on the scales will inevitably straightjacket innovation..."
Cableco #2: "...puts the Commission's thumb on the scale by endorsing..."
they've really given up on pretending they're not a cartel, haven't they? Do they just have one PR department between the lot of 'em, to save a bit of money for spending on the executive suites?
Millions of people annually around the world "wade their way through" at least one of Shakespeare's plays, as a cursory glance at just about any theatre program would show you. They don't put on all those productions to empty houses, you know. Theatres are - believe it or not! - subject to the guidelines of supply and demand just like everyone else.
(Sidebar to this debate: the most tiresome thing for me is the assumption that what you study in school or university somehow determines your path for life, and is really only of interest insofar as it "gets you a job". I've got a degree in history. I work in software. I know there are a lot of other people like me - if you do an informal count among any reasonably-sized gathering of software engineers, you'll wind up with ~25% with "liberal arts" degrees, in my experience. To a large extent, the point of study is not so much what you study as the techniques you learn by studying it.)
"At the time, the thesp boasted that Pushnote “makes the web one big democratic comment platform.”"
ah, the innocent days when this was considered a *sales pitch* and not a dystopian vision.
UEFI will be used by many aarch64 systems.
The efivars are mounted writeable because *we actually need to write to them*. The UEFI boot manager, for instance, is controlled in this way; if you want to modify the boot configuration, which is a perfectly normal thing to do, you write an efivar. They're explicitly *intended* to be writeable.
This isn't a problem with UEFI, it's a problem with bad implementations of UEFI. Any decent implementation should boot without any efivars set, there's no reason why the firmware should assume any will be set.
There have been bad firmwares since time immemorial. There are certainly lots of terrible BIOS firmware implementations. UEFI has no kind of monopoly on being implemented badly.
UEFI is not Secure Boot. UEFI existed for many years before Secure Boot. Secure Boot is an effectively optional part of the UEFI spec that was added in later revisions, and really isn't particularly tied to it; the desire for a cryptographically secured boot chain has existed for a long time and would have existed if UEFI had never been created. If UEFI hadn't been around, the same idea would just have been attached to some other firmware format (you could build something like Secure Boot on top of BIOS, if you really wanted to).
UEFI is a development of EFI, which was created by Intel, not Microsoft. It's maintained by a consortium of pretty much every significant company in personal computing, including Microsoft but also everyone else.
You can't "disable UEFI". It's an absurd concept. It's like saying "disable BIOS". If you "disable" your system's firmware it's not going to do anything.
You can ask a UEFI firmware which has a CSM to boot in BIOS compatibility mode. That's what you're talking about, but it's not at all the same thing.
Sigh, you really do protest too much, Andrew.
The reason this is bad is perfectly simple: it establishes the principle of a two-tier system. Once you get that in the door, it's very hard for anyone to later complain when they change the 'details' of the system.
So of course they introduce it with 'details' that seem nice and unthreatening: instead of charging more for things outside the scheme, we're charging less for things inside the scheme! Isn't that nice? Charging less is always good, right? We're not even charging partners to sign up! See, it's free! Who could possibly complain about free?
Well, the problem is the pricing numbers are just numbers. Once they've got the trojan horse in the gate, they can twiddle the numbers any damn time they like. Two years down the road the scheme will cover a lot more large, rich companies, but suddenly you'll be paying twice as much for data outside the 'scheme'. But who cares, right? All your tweetfaces are inside the scheme! A bit later they'll make some mumbly noises about overheads and start charging providers to join the scheme, but who cares, right? We can still see our tweetfaces for free!
Then just wait until they need a revenue injection and start re-introducing charging for data within the scheme...and oh look, we've got the differential pricing that was supposed to not be allowed in the first place.
There's an argument of course that there's nothing really wrong with allowing this sort of tomfoolery in a reasonable simulacrum of a free market. AOL and Compuserve got competed out of existence, we didn't need laws for that. But cellular network markets are rarely particularly good examples of ideal capitalism.
"Who determines the level of 'extremism' of a group? Few would disagree that law enforcement and intelligence services should have the ability"
Few people, I suppose, except the hundreds of peaceful and legitimate political organizations that were infiltrated by intelligence agencies in the US, the UK and elsewhere, apparently for no particular reason other than someone in a position of authority didn't like the cut of their jib?
(see the unfolding story about undercover spooks *getting engaged to people* in such organizations, thus entirely ruining their lives...)
I haven't read the article, but please, *please* tell me the new definition reads something like "colloq. - not literally".
"That said, RHEL makes a compelling workstation, particularly if you like GNOME's fallback mode, which RHEL uses to make the desktop feel a bit more like GNOME 2.x. "
Nitpick - that's not a "fallback" mode. It doesn't have any lower graphical (or other) requirements than the regular mode. It's just an alternative UI for people who prefer a more Win98-style desktop. It's officially called "Classic mode".
Back in the early days of Shell there was a "fallback mode", which actually used the old GNOME 2 components (more or less) and was explicitly intended for hardware which couldn't handle Shell, but which some people forced in order to get a more old-style desktop. Classic mode is not fallback mode, they're different animals.
One of my favourite perl things is how, somewhere in the official documentation, it says something like "Look, whatever syntax you're using to writing, just try that, and it'll probably work".
"Bollocks! If I fancy a beer, I shall bloody well have a beer!"
Well yes, yes you will. It's a free country. That's why the government health body issues *guidelines* and *recommendations*, not orders. So I'm not sure exactly what brave stand you think you're taking because everyone would be perfectly happy to acknowledge that yes, you have the right to drink however the hell much beer you like.
"with moderate drinking defined as men who drink about three pints a day and women who have two glasses of wine a day."
Er, I really don't think that can be right. IIRC a pint is counted as two units. Three pints a day would be 42 units a week. I'm pretty sure that's never been considered 'moderate'. I suspect you were shooting for 21 units a week, which would be a pint and a half a day.
"Expect less SHOUTINESS, an evolving sense of humour, more modern and global cultural touchstones, science coverage that gives proper prominence to peer-reviewed, evidence-based research and a recognition that attempted self-aware hopefully ironic sexism is almost always indistinguishable from actual sexism."
This is great news. Might even start reading regularly again. Thanks, El Reg.
It's exactly like that. You get to be part of a 'community' where everyone pretends to be wildly interested in where and how fast everyone else is riding their bike, the payoff being that other people will pretend to be wildly interested in where and how fast you're riding *your* bike. Doesn't that sound fun?
No, not really. grub is a generic bootloader, you can use it to boot anything. And this doesn't exactly root anything, it bypasses a very specific form of protection - as discussed upthread, the grub password really only protects the grub configuration, and is only useful at all in extremely limited circumstances. Drive encryption and firmware-level passwords are much more generally useful for limiting access to a system.
"and more importantly is it 'trusted' by the majority"
Yup. The OP has a graph with a sane Y axis (starting at 0) sandwiched between three 'gee whiz' graphs, for no apparent reason (figs 7, 8, 9, and 10).
Also note that the network tests were the *only* ones which showed any significant difference in power consumption. So El Reg pulled out the most misleadingly presented graph from the most extreme of the conditions tested.
As the OP's conclusion says:
"The results show that the power consumption of hypervisors and containers is similar when challenged with heavy CPU and memory workloads. Some differences can be observed in the case of network performance analysis, where, for most of the cases, both of the container solutions introduce lower power consumption."
Implementation and support deal with Collabora, basically. You can follow Michael Meeks, an LO dev who is involved in the whole thing:
if, er, you don't mind the constant updates about going to church. Read the ones like http://www.gnome.org/~michael/blog/2015-10-20.html .
Because banks assume liability for bonk transactions - i.e. if you challenge them, unless the transactions look wildly suspicious or you have a history of doing it, they'll just refund you. It's not really more secure, but it's true that the consumer's exposure is pretty limited. (And there is the fact that you really do need to have the card or a very good facsimile in close proximity to the reader, i.e. somewhere you'll be on a camera).
The banks ran the same numbers Starbucks ran a few years back, when they stopped bothering to ask people to sign credit card receipts (and hence assumed liability for the transactions) - whatever they lose on the few people willing to faff around stealing $4 lattes, they gain more on the shortened transaction time for the far greater number of honest customers. Ditto for bonk payments, which is why there are various caps and cutouts, not just the single transaction limit. (If you tried the whisky wheeze you'd find PIN prompts would start showing up somewhere around the fourth or fifth bottle shop).
Actually this isn't really North America, just the U.S. Canada more or less moved everything to chip and PIN at the same time as the rest of the world, and most retailers have bonk now too. It's only US banks that are behind. Canadian retailers (especially near the border) tend to accept chip-and-sign to accommodate travelling USians, but all Canadian cards are chip-and-PIN.
"It's machines learning the behavior of other machines [to ensure security]"
Oh, good, nothing could possibly go wrong there, then. And it'll be really easy to audit.
"In addition, the researchers believe that creating a system to automate the callback process for those accidental dials will help save time"
If you are being murdered in your own home, please press 1 now. If you would like to hear about Google Now On Tap from our friends at Google, please press 2 now...
GNOME 3 shows a thin scrollbar whenever the active window has scrollable content.
Yeah, the first-time catch 22 is why we (distros) typically leave it available by default. You need to be able to get into a remotely-deployed server one time to set up keys and such. You should disable direct root access and password access after that.
Out-of-band access mechanisms are fine and all, but tend to be security nightmares in their own right...you can find some pretty hair-raising analyses of some implementations.
I think you're operating with an excessively simplified definition of 'server'. Several things in Linux use the 'client/server' paradigm entirely within a single system. You can't just run around turning off everything with the word 'server' in its name or definition, please at least try and understand what it's for first. Just because something's a 'server' doesn't mean it's binding to a remotely-accessible port.