Perhaps instead of trying to be all things^W^WChrome to all people, they would do better to go back to their roots as the simple, expandable browser the AC mentioned, and perhaps focus on the robustness issues with plug-ins and cross-tab contamination that have plagued them for so long.
Unfortunately these two things are somewhat conflicting. They are working on a process-per-tab/plugin implementation ("Electrolysis") but it will require changes to many add-ons.
If it's an entry level job I think it's unreasonable to expect applicants to have experience with a large, complicated and - these days - quite specialised language. It's not as if they teach it at most universities any more.
Even if (in theory) they aren't downloading my browsing history and it is my browser making the requests they can deduce what sites I must be browsing to request such "suggestions."
According to the bug report for this feature, the intent is that any suggestion would be triggered by multiple visited sites, so this wouldn't reveal exactly which sites you had visited. Still, it obviously does leak some information.
I'm supposed to download binaries that don't have Authenticode signatures, from a web server that doesn't support TLS.
And then I have to download (and somehow verify) a copy of PGP or GnuPG, in order to verify the signatures they do provide. (I also have to know and remember the fingerprint of the genuine PGP signing key.)
Finally, I have to trust that no-one has cracked a 1024-bit PGP key.
I can only assume that almost all downloads from the official site are vulnerable to MITM'ing. And, as PuTTY is such a popular tool, it is surely a prime target for that.
A win for rude, pushy and obnoxious people who shouted loudest and longest and ignored everyone else...
Well that's what I see from the systemd detractors, not its proponents. They're still shouting loudly, in the comments on every article even tangentially related to it. Of course they are being ignored by systemd proponents and most neutral parties because they mostly repeat the same myths and slurs.
Sorry about that. Once you've recovered, consider running 'reportbug release-notes' to request an additional note about this gotcha. (I assume that there is already a bug report against grub).
A true free and open process would be to include a choice at installation/upgrade time between the choices. If I do have a choice on the web server, on the DNS server, on the mail server, even on the kernel, on the shell that I deliver for my users [...]
You can't choose any of those through the installation GUI. All of them require a custom pre-seeded install or post-install action.
If you upgrade an x86 system, both systemd and sysvinit will be installed and you can select sysvinit from the GRUB menu.
Because it wasn't tested well enough? For example, in the case of the system call entry path, Andy Lutomirski found a bunch of bugs over the past few months - including CVE-2014-4508, CVE-2014-9090 and CVE-2015-2830. His changes for 4.1 include the addition of regression tests as well as cleaning up that code.
Yet all the browsers consider unencrypted connections more secure than connections encrypted with a self signed certificate.
No. They consider that entering or following a link to an 'https:' URL means that you expect a secure connection. In this context, a self-signed certificate that has not been whitelisted is an error.
This is good news; I'm glad to see at least one misogynist leaving Wikipedia.
Sadly, it still seems to be run by a bunch of young white guys fighting for the importance of hosting porn and claiming the consensus of their privileged group is "neutral". ArbCom has censured admins for fighting back against lies spread by GamerGate, with a ban that may apparently prevent them fixing any abusive edits to articles about women.
As described, It is full duplex - both sides transmit simultaneously and have to cancel their own signal and its echoes from the combined received signal. Twisted-pair Ethernet already works this way, but in the radio medium the echoes must be even more challenging to model and cancel.
USB host controllers generally support DMA, but the drivers on the host do all the buffer management so the device cannot choose which addresses to read and write. Of course, it can take advantage of driver bugs such as the HID descriptor parsing bugs that were fixed in Linux a few years ago.
This is why I claim it's spyware. Sure, you can turn most of those things off, but the intent of turning them on by default is to capture that information from most users.
you know what I don't use every day? Debian, Do you know why? People like you. I've been using Linux for 20 years and it's people like you that get in the way of progress.
Linux 3.19 is already packaged in experimental and I expect to end up maintaining a linux package in jessie-backports, so that will be another option for people who really want to use Chrome/Chromium.
I do dislike Chrome and I'm not going to pretend otherwise. Aside from its being spyware (in its default configuration), the Chrome/Chromium developers have previously added requirements that make Chromium unsupportable in Debian 7. We could add this kernel feature now, but I strongly doubt that will be sufficient to keep Chrome/Chromium running on Debian 8 until its EOL.
Please note that I am not NAKing the change, but I'm also not going to be the one to make it happen.
Unfortunately these two things are somewhat conflicting. They are working on a process-per-tab/plugin implementation ("Electrolysis") but it will require changes to many add-ons.
There may be a bug in Skype but if an application can crash the whole system that's a kernel bug by definition.
That's not Skype's fault, that's a bug in a driver (or other kernel component).
If it's an entry level job I think it's unreasonable to expect applicants to have experience with a large, complicated and - these days - quite specialised language. It's not as if they teach it at most universities any more.
According to the bug report for this feature, the intent is that any suggestion would be triggered by multiple visited sites, so this wouldn't reveal exactly which sites you had visited. Still, it obviously does leak some information.
I can only assume that almost all downloads from the official site are vulnerable to MITM'ing. And, as PuTTY is such a popular tool, it is surely a prime target for that.
Since they realised their customers were going to use a mixture of systems anyway. For example, they turned off a feature in the Windows CIFS client because the server side was broken in Samba.
Do you really believe you are replying to Linus? The username isn't even spelt right.
Do those really exist?
Well that's what I see from the systemd detractors, not its proponents. They're still shouting loudly, in the comments on every article even tangentially related to it. Of course they are being ignored by systemd proponents and most neutral parties because they mostly repeat the same myths and slurs.
Sorry about that. Once you've recovered, consider running 'reportbug release-notes' to request an additional note about this gotcha. (I assume that there is already a bug report against grub).
You can't choose any of those through the installation GUI. All of them require a custom pre-seeded install or post-install action.
If you upgrade an x86 system, both systemd and sysvinit will be installed and you can select sysvinit from the GRUB menu.
Debian had a GR to decide this issue, so please don't spread conspiracy theories about "a small handful of people". Good luck with FreeBSD.
Debian 8 has libjpeg-turbo, replacing libjpeg8 and matching most other distributions.
Please read the release notes, there are various things that may need manual attention before you upgrade.
Because it wasn't tested well enough? For example, in the case of the system call entry path, Andy Lutomirski found a bunch of bugs over the past few months - including CVE-2014-4508, CVE-2014-9090 and CVE-2015-2830. His changes for 4.1 include the addition of regression tests as well as cleaning up that code.
No. They consider that entering or following a link to an 'https:' URL means that you expect a secure connection. In this context, a self-signed certificate that has not been whitelisted is an error.
No, they did not. There are a lot of the same players there, of course, but they have no formal relationship.
This is good news; I'm glad to see at least one misogynist leaving Wikipedia.
Sadly, it still seems to be run by a bunch of young white guys fighting for the importance of hosting porn and claiming the consensus of their privileged group is "neutral". ArbCom has censured admins for fighting back against lies spread by GamerGate, with a ban that may apparently prevent them fixing any abusive edits to articles about women.
Maybe part of the problem is letting HR filter them first. If they don't know how to spot bullshit then they may effectively favour the liars.
As described, It is full duplex - both sides transmit simultaneously and have to cancel their own signal and its echoes from the combined received signal. Twisted-pair Ethernet already works this way, but in the radio medium the echoes must be even more challenging to model and cancel.
USB host controllers generally support DMA, but the drivers on the host do all the buffer management so the device cannot choose which addresses to read and write. Of course, it can take advantage of driver bugs such as the HID descriptor parsing bugs that were fixed in Linux a few years ago.
This is why I claim it's spyware. Sure, you can turn most of those things off, but the intent of turning them on by default is to capture that information from most users.
I'm not getting in the way of anything. The kernel is team-maintained and I've explained how this change can be made without my help.
Linux 3.19 is already packaged in experimental and I expect to end up maintaining a linux package in jessie-backports, so that will be another option for people who really want to use Chrome/Chromium.
I do dislike Chrome and I'm not going to pretend otherwise. Aside from its being spyware (in its default configuration), the Chrome/Chromium developers have previously added requirements that make Chromium unsupportable in Debian 7. We could add this kernel feature now, but I strongly doubt that will be sufficient to keep Chrome/Chromium running on Debian 8 until its EOL.
Please note that I am not NAKing the change, but I'm also not going to be the one to make it happen.