Re: Oh, they've replied now.
Wow, an expiry time is a business model now? yeesh.
949 posts • joined 4 Nov 2010
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.
"Initially, attackers gain root access by brute-forcing a machine's SSH service – disabling root login from SSH, or using a very strong password, will defeat this."
As will disabling ssh access with a password at all. There's rarely a good reason to allow this; set up key-based access instead. (And of course, use a strong passphrase for your keys).
The 'disruption' concept is kind of the opposite of an 'ivory tower' thing. It's mostly being recited by businesses operating in the 'real world' as some sort of mantra against criticism of any kind ("BUT BUT WE'RE DISRUPTORS SHUTUP SHUTUP NOW"). It's the people in the ivory towers pointing out that it's bullshit. You get a nice clear view of the situation on the ground from an ivory tower - much better than the people on the ground have. Which is why people built 'em in the first place.
We didn't write grub2. RHEL 7 uses it because no-one is interested in maintaining grub-legacy, and there's no viable alternative. No-one particularly loves grub2, but no-one seems to hate it enough to make something better.
You can still edit grub.cfg by hand in RHEL / Fedora; the scary warning telling you not to comes from upstream grub2, which expects the config file to be updated by grub(2)-mkconfig, which does indeed nerf manual changes. In RHEL/Fedora's system, though, the config file is updated (on new kernel installs and so on) by grubby, which does not nerf existing manual changes to the file.
The grub2 file does look a bit scary at first but a lot of it you can pretty much ignore, if you're just wanting to change kernel boot parameters and the like you can just find the appropriate lines and append the parameters you want, just like before.
I'd say that's a complete misunderstanding. I can see where the idea comes from if you don't know anything about how RH works, but it looks nothing *at all* like that from where I'm sitting. systemd isn't really a Red Hat project at all. It's a Lennart project. Lennart isn't an RH plot; he's an engineer. RH hired him based on his Avahi/PulseAudio work. No-one ever told him 'hey, Lennart, Red Hat wants to own init now. Go write an init daemon, and make it a big one.' He just got interested in the area and decided to write something; same as he did with all his other projects. He'd have done the same if he'd been working for Wal-Mart.
systemd got adopted in Fedora because Lennart proposed it and fought the technical merits until he won. It got adopted in RHEL for the same reason. It came from the bottom up, not the top down - there wasn't some PHB somewhere coming up with a strategic vision for the future that involved an init system, it was an engineer pushing something he thought was good. If you want to look at the stuff that actually *does* come from Red Hat's strategic vision and gets dropped into Fedora, look at stuff like Cockpit and FreeIPA and to an extent the Cloud stuff (though some of that is engineer-driven, too). That's the stuff RH's 'strategic vision' is resulting in. Not init systems.
It doesn't really *benefit* RH to 'own' init (not that we do; even if you accept that Jude person's point that there are ~10 core contributors to systemd, half of those don't work for RH). That's not much of a selling point to any of our customers. It's just more work we have to pay someone to do. Have you looked at RH marketing lately? Have you seen how much of it is about systemd? That would be 'none'. It's all hybrid cloud this and container that and devops the other. I mean, I just went to https://www.redhat.com/en and clicked around the marketing crap aimlessly for about 10 minutes and the word 'systemd' didn't appear once.
Oooh! I finally found it, on page 6 of https://www.redhat.com/en/files/resources/en-rhel-whats-new-in-rhel-712030417.pdf , which is six clicks from the front page, one unobtrusive link on https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux . Prominent, this ain't.
Er, no. Believe it or not, not everything is about systemd. I was talking entirely literally about climate change. I stopped reading this site regularly back a few years ago when they'd post a new anti-climate-change wibble from Lewis Page every day - he's still at it, see http://www.theregister.co.uk/Author/93/ , though he seems to have slowed down a bit.