I was debating the merit of having the pdf reader bundled and on by default, instead of having the pdf file downloaded like most other files.
One can certainly change firefox's behaviour in the settings (unlike webgl).
194 karma · joined March 14, 2015
Also, the links/lynx jokes have really gotten tired, plenty of people browse the web with ublock, no(t)script, webgl and webrtc disabled and so on. The pretense that anybody who tries to retain a modicum of control on what its browser does and does not it a luddist is frankly irritating.
And the whole language debate is completely off point, we have plenty of safe(r) languages for writing stuff, the misguided idea is that the only way to do so is to use javascript and stick the resulting program inside the browser.
What innovation and what benefits do I reap by using pdf.js? It's slower and has less features than okular. It's stuck inside a firefox window, so I cannot add a window rule for it (barring adding one for firefox in general).
The same holds on windows: why would I use pdf.js when there are faster, lighter pdf readers (e.g. sumatra) or the actual adobe acrobat reader and its eight bilions features? Heck, I've also noticed that many users will skim the file and then forget to save it, so it doesn't even help less tech savy users.
There are genuine improvement in the new web technologies, but they are mixed with a lot of stuff that simply does not belong there, and with the insufferable attitude "you can do in javascript, hence you should it in javascript" (I'm not criticizing you, eh, and there is some security argument to be made).
From what I remember from Coles-Lucchin, the finite age of stars does furnish a partial explanation: keeping the average density of lit stars the universe constant, does not solve the problem, since in general, when I look in a particular direction, any star in that direction will either be dead or lit, but still too far away for its light to have reached me.
Indeed the opposite would require fine-tuning the stars ignition time so that there is sphere of burning stars at the right distance.
On similar note, I rememember someone arguing that the baloo/nepomuk db was a security threat, I guess since it makes slightly easier to search among the files on the system for a string like "password".
Both claims are technically true, and in neither case I believe they are practically relevant, neither for security nor for privacy. I was nitpicking, I guess.
Qupzilla-git i.e. the version based on Qtwebengine is getting there, so reasonably soon we may have a decent Qt-based browser (I don't doubt scrollaway knows that). Also the fiber browser looks promising. I do think we need a way to do CI between chromium and Qtwebengine, or else we'll end up shipping browsers lagging one or two versions behind chromium.
As far as gecko goes, I think it's over. The hope is servo, which being much more modular may be integrated without struggling with XUL.
In the end I'm always puzzled when people talk about Microsoft or Apple as if it was one dude who ran over your cat in the early 2000s. It's a vast corporation, whose attitude towards opensource has improved, at least in the cloud and .NET environment (though I've read people comparing Microsoft to Red Hat and Joyent, which is clearly way off). For instance, the issue I find most egregious is selling Windows phones with a restricted bootloader, just like Apple does.
It does increase security, since for instance in spite of its complexity Secure Boot has proven to be reasonably secure, and thus it is simpler to attack the firmware.
However I agree with Garrett and disagree with aaronem: just as shown by Secure Boot on x86, you can have a reasonable choice between security and user's choice i.e. you can give freedom and security. A similar mechanism, in which a user could enroll its keys and install its signed coreboot payload, is possible. The same applies to TPM. Given that Intel had 55 bilions in revenues last year, I see no reason to cut them any slack (same goes for Apple, Qualcomm, etc).
As far as the "new Microsoft" goes, the policy on Windows phone is the same on Windows 10 as it was on Windows RT and Windows 8: Secure Boot on ARM is locked down in such a way that the user cannot add its own keys, or send a binary to Microsoft to have its signed for 99$ (i.e. the result is functionally equivalent to Apple policy with ios). If you sell devices on which the users can't even decide which kernel to boot, you probably don't have a problem with devices in which the users can't decide which firmware to use.
There are other CLI editors. I'm quite partial to ne (the Nice Editor), which has more manageable shortcuts than emacs, a command line (it's still a non-modal editor, to be clear), macros and syntax highlighting. Also jed is not bad. While vim (and nvim) have advantages, and certainly benefit from being ubiquitous and having ther shortcuts replicated in other programs, users should shop around, even on the command line.
As far as the iwatch being just a watch, the same thing could have said of the iphone. It was a phone, only cooler. Almost a decade later, ios devices are the platforms where many users do a significant fraction of their computing. And while ios devices may not require on bitcode submission, they limit the users freedom in a way that is fundamental. Image a world were every x86 computer sold post 1995 (outside of the server space) could only run Windows.
Besides, even if you own a "creation machine", you'll often be catering to the market of restricted devices (case and point: gecko on ios).
EDIT: I'll grant you may be right in the specific sector of non-computing electronics (watches, calculators, etc).
I've read quite a few complaints about Ubuntu 15.04+btrfs problems, for what is worth I had no problems with Fedora22 and Opensuse Tumbleweed.
On the second and the third point I'll both agree with you and continue disagreeing. Yes, in some places a FirefoxOS is the only option. And yes, negligible is was a dickish term. But I was specifically talking about points on a graph. This doesn't make the project worthless (as I guess my post made it sound), but, IMHO, also means that the result will not fundamentally change the trajectory of the web and of the mobile market. One can obviously reply that giving someone their first smartphone should be enough, and that is a perfectly tenable position.
On the specific example of those two countries, I'll happily take back my complaint.
1. As far as the effect of the window manager: this isn't emacs+X11 in 1995: the drag on CPU/ram/battery of gecko/blink will dwarf the "weight" of the windowing system.
2. FirefoxOS maybe be leaner in principle, but the competition has vastly better hardware, both in the Windows Phone field and in the Android one, via what I can guess is a combination of subsidies (is mobile MS still burning piles of cash or has the division posted some profits?) and sheer mass scale production. So, for little more money you get a get a better device that actually runs all the apps that your friends have, and a web browser.
3. The appeal of FirefoxOS even in those low end markets was negligible (this has been discussed to death). Besides they released phones in places such as Italy and Spain, two markets were people will en masse shell out the cash for an Iphone. I found that simply baffling.
https://github.com/lxc/lxd https://insights.ubuntu.com/2015/03/20/installing-lxd-and-th...
I've just compiled it on Fedora 22 and both the daemon lxd and the cli tool lxc seem to work, haven't tested any container however.
As far as pinning goes, however, I disagree: if you mark a package as IgnorePkg it does not get updated. You could use either naming conventions or splitting the repos up to track different repos for different packages, but it starts looking like an antipattern to me (i.e. the way you would have firefox track jessie while you are on wheezy would be by setting up your own repo only for firefox, a bit of an hassle). It's fine if you are the packager, it's a bit cumbersome if you want a stable debian box with a fresher version of django and nginx.
After all the road map for pacman 5.0 proposes hooks and a better handling of optdepends. Both can be already automated via scripts, but both would be nice to have out of the box.
Would you take debian, with its three branches, and move it to pacman? No, because the lack of pinning and differentiation between security upgrates and normal upgrades would wreak havoc ("get a better upstream" is a nice suggestion, but an unpractical one). The same could be said for Fedora (actually, for Red Hat, but Fedora is Red Hat testbed after all).
I could set up my own repository, clearly, it may very well be a good solution, but to me that is not automation anymore. Similarly, there is nothing preventing one from setting up one's own repo of old packages, and reinstalling those. Still, I see the value in having the rollback features inside DNF (call it laziness, if you wish). I guess my comment came out as random pissing on Arch, when what I wanted to point out was that other distros simply have different needs.