"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.
931 posts • joined 4 Nov 2010
"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.
The RHEL default desktop isn't a server GUI. It's a desktop GUI. People run RHEL on desktops; we have major customers running multiple thousands of seats on it. That's what the RHEL desktop is for.
Probably most people running RHEL as a server OS don't run a graphical desktop directly on the system at all; those who do usually run something pretty geeky and minimal, not GNOME. That's not what GNOME is for.
RH is working on 'server GUIs', but more in the line of webapps than graphical desktops running directly on the server machines. See, for e.g., Cockpit - http://cockpit-project.org/ , included in F21 Server - and the FreeIPA web UI - demo site at https://ipa.demo1.freeipa.org/ipa/ui/ .
"If you guys were that great in changing the design of Secure Boot why didn't you change it to allow replacing the Microsoft public key ?"
The UEFI specification's Secure Boot definition does not make any requirements whatsoever regarding who should be the provider of the platform key, or any other key, or whether any keys at all should be provided in any particular firmware implementation.
The Microsoft labelling requirements explicitly require that the system owner be able to replace the Microsoft key. Look, they're right here: http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256.aspx
"On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:
A.It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.
B.If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off."
"Let's not forget that by doing what you did you prevented the rest of the Linux community to stand up and fight"
What do you mean by 'doing what we did'? And how did that prevent anyone else who gave a crap from pulling their finger out and doing something useful?
"Those who like systemd should do a forensic exam of a failed system, do this using a linux that does not support systemd."
Why? What's the point of that entirely artificial restriction?
You can install any package set from the 'Server' network install image, it is really a generic network install image. The Product stuff is a first cut in F21, it's still being shaken out; this kind of quirk will be straightened out for F22/F23.
You can use the Server network install image to deploy any package set. The generic DVD image is gone, though - something had to give, with the Product changes. Sorry about that.
Er, if anyone was paying me to do PR, they'd want their money back, I think. No-one's sending me anywhere to do PR, my job is QA. This I do on my own time, God knows why. I've been posting here since it was a useful tech news site and not some sort of weird climate change sceptic backwater, and long before I worked for RH....
If you'd rather use something with a long life cycle, that's entirely up to you, but it's kind of presumptive to assume you speak for everyone "who use our machines as a tool to get on with our actual work".
Fedora's life cycle is ~13 months (technically it's 'until one month after the next release but one comes out' - F19 goes EOL in a couple of weeks). That's not like RHEL, or anything, but many people find it perfectly viable for getting all sorts of 'actual work' done, and upgrades generally work well these days.
"Nitpicking aside, answer my original questions about the necessity of a qr code lib and a http server for journald."
Simple: they aren't necessary. Fedora's systemd does not require an HTTP server:
[adamw@xps13 ~]$ cat /etc/fedora-release
Fedora release 21 (Twenty One)
[adamw@xps13 ~]$ rpm -q --requires systemd | grep http
Fedora's systemd is built against qrencode, but that's a Fedora choice:
[adamw@adam anaconda (master %)]$ cd ~/local/systemd/
[adamw@adam systemd (master %)]$ grep -R qrenc *
configure.ac:AC_ARG_ENABLE(qrencode, AS_HELP_STRING([--disable-qrencode], [disable qrencode support]))
Build systemd with --disable-qrencode if you don't want it to have a qrencode dependency (or in fact just don't build it with --enable-qrencode , disabled is the default). The benefit is some convenience when setting up keys for Forward Secure Sealing of journal contents; see the --setup-keys argument in 'man journalctl' for details.
As for the HTTP server - again it's a compile time option, --enable-microhttpd to turn it on. Fedora does in fact build with it, but then splits it out into a subpackage so the core systemd does not depend on microhttpd. The subpackage is systemd-journal-gateway . As that name suggests, the feature it supports is allowing remote access to the journal; the thinking was that there's a handy protocol lying around for reading information over a network which everything and its dog supports, so why not just use that instead of inventing some new protocol for remote accessing journal data? See http://www.freedesktop.org/software/systemd/man/systemd-journal-gatewayd.service.html . Of course, even when the package is installed this is not enabled by default, and the package is not installed by default.
"Of course the broader question is why does so much of systemd, which is replacing the OS incrementaly, need to reside in user space?"
Erm. Why would you want to build it into kernel space?
"Why the single point of failure in PID1?"
There's *always* been a single point of failure in PID 1. That's sort of what PID 1 *is*. Note that much of systemd does not run as part of PID 1. systemd-journald, for instance, is pid 559 on my system as I write this. systemd-udevd is pid 606. systemd-logind (the daemon GNOME uses, for the 'GNOME requires systemd!' haters) is 871.
Actually, we're the guys who got the original Secure Boot implementation designs substantially changed to be less sucky. Without the RH representatives in those discussions, all systems with Windows 8.1 pre-loaded would likely be as locked down as an iPhone.
Thanks for the review, glad you enjoyed F21 overall!
"Given the base system shared by these new flavors, I hoped there might be a plain, base flavor - something akin to Debian's Minimal install, which would let you build a more customized desktop. But so far that's not something Fedora is doing. In fact, the Fedora project emphasizes that the base set of packages is "not intended for use on its own"."
Where did that "not intended for use on its own" quote come from? It might need tweaking. You certainly can do a minimal install of Fedora, and it's fairly common. It won't be a Product, but it's a perfectly valid Fedora install. To do it, use the Server network install image, go to the Software Selection screen and pick the 'Minimal Install' option, it's all the way down the bottom of the left-hand column. (Note for the haters: Minimal still uses systemd, NetworkManager and firewalld. Sorry, haters.)
"With Fedora's installer it isn't immediately clear what you need to do – or even that you need to do something"
Well, er, there *is* a rather bright orange bar at the bottom with a little attention icon, that says "Please complete items marked with this icon before continuing to the next step." And the spokes you have to complete - only Installation Destination is required, usually - are marked with that attention icon. Was this not visible enough?
"GNOME on Wayland is still very rough around the edges and there are a number of apps that won't work with Wayland (some of which might never be ported to use the Wayland protocol)"
Note that most of those should still run in a Wayland *session*, via XWayland. In fact I think it's still the case that most apps run via XWayland in Fedora's Wayland GNOME session by default - GTK+ 3 does *have* native Wayland support now, but it was still so crashy the devs decided not to use it by default yet.
"Other Fedora 21 highlights include some SystemD updates"
Nitpick: it's systemd, all lower case. The 'SystemD' spelling tends to be associated with the comment thread monster raving loony faction, so the devs get sensitive about it.
Thanks for all the kind words!
If we're losing this much of your money right now, think how much *more* we could be losing in a year's time!
Matt Miller (current Fedora project leader) has a take on 'delays' which I hope people will consider:
Fedora's release schedule is a hybrid of time- and feature-based, which perhaps isn't always best communicated (and it's much easier to look at a date and say 'hey, it's that date and this didn't happen' than to understand all the subtleties behind it).
F21 was never planned to be a six month release cycle from the start, and was pretty much expected to have some bumps, since there's so much change involved.
Aside from that, glad you're enjoying the Beta so far. We hope the Final shouldn't diverge too far from the current schedule (we really don't want it to drag out past December).
There's a bug report for the Facebook issue:
which notes that you can actually navigate the Facebook UI behind the 'too small!' overlay using tab and enter, and authorize the account that way, as a workaround. That works, I checked (though it's a bit tricky to see).
"In Fedora, for example, most of the account setup process is handled in the Anaconda installer, thus bypassing the GNOME version."
Not in fact. You aren't required to create a user account in anaconda; you have to *either* set a root password *or* create a user account with admin privileges (otherwise we can't be sure you'll have root access to the installed system). If you just set a root password in anaconda, you'll get the no-user-created-previously version of GNOME's initial setup tool.
Even if you create a user in anaconda, you still get most of the GNOME initial setup process after first boot. The only step missed is the user creation step, because...you already created a user. Seems sensible. You should still get the bits about language, keyboard layout, and online account configuration (and anything else I forgot).
Thanks for the bug report about Facebook user accounts - I'm about to see if I can reproduce that here.
"Still a touch-oriented UI on a non-touch desktop"
No, it really isn't. If it was touch oriented, you wouldn't see this:
"Still missing 99% of the functionality of Gnome 2"
"Still hard-wired to systemd (why does a DE have a dependency on a specific init system?)"
It doesn't. It has a dependency on a decent session manager. ConsoleKit wasn't one. logind is. If someone had written a good one that wasn't part of an init system, GNOME would happily use that. If you write something else that implements the logind API, GNOME will work fine with it.
"Still bloated beyond belief"
Wait, I thought the cool thing to say about GNOME was it didn't have enough features? How can it not have enough features yet be bloated beyond belief? I'm confused.
"Still driven by sneering twits like Lennart "do you hate handicapped people" Poettering"
You appear to be confused. Lennart is not a GNOME developer.
"which would seem to fly in the face of GNOME's belief that features confuse users"
There is no such belief. It's just an invention of snarky tech journalists. More actions on right-click in the Dash have been planned all along; just the devs got around to doing it now.
Don't worry, future archaeologists will find your body in the vast cavern labelled KDE Control Center in a mere handful of thousands of years ;)