You might want to reread that. It's not supporting it, it is just ignoring the certificate error and indexing the site anyways. On the plus side it will work by accident as long as you don't tell apache to redirect to an error page on SNI failure. So it's mostly good news.
Bing and Yahoo's web crawlers do not support SNI so you can enable it as long as you don't mind not being indexed on some search engines.
That said, GP nails it: the problem with SSL is not the tech, it's the that the CAs are money grubbing semi-competent boobs, and the trusted certificate lists are administered by either OS or browser producers leaving a huge open arena for politics and perverse incentives.
Which is why it was really sad when chrome backed off on supporting DANE
Uh no, the Linux kernel is monolithic because it runs the drivers as if they were a part of the kernel rather than running the drivers as separate processes.
It isn't in the actual init system, it is an optional daemon that uses the interfaces that systemd exports so there is nothing that actually forces anyone to use it. My Debian based firewall runs systemd with unbound without any problem.
Did it actually not boot or did it seem to hang and the guy resets it after a minute? I ask because my PC had exactly this problem. Ages ago I had a drive die in my system so I pulled it but missed one of the references in
The systemd update a few weeks ago finally gave me a nice message on console to let me know that one of my fstab entries was timing out so I checked, found the entry and now everything boots faster.
And the criticism from those who are against systemd is extremely important to consider. The complaints are very sound, from a technological perspective. They're also based on decades of real world experience, which just cannot be ignored.
I'm not a total fan of every design feature of everything systemd has done but gave you actually read their supporting references? I'm most of the cases boycottsystemd has rephrased events to make the systemd folks look as bad as possible in ways that would make a Fox news reporter feel proud. A good example is their comment about requiring "bug for bug" compatibility with glibc was instead a use of a certain non posix flag needed for thread safety and complaining that it is tightly tied to Linux is about as helpful as complaining that udev is tightly tied to Linux.
At any rate, I find it very telling that they don't actually mention any of their supporters.
64bit... again, bragging points about how many bits you use, no functional difference to anyone. Its like when I gave the 32 bit version of Visual Studio to a colleague and he complained that he wanted the 64 bit version.... there is no 64 bit version because it isn't needed. Its just the typical knee-jerk reaction that 64 bits is somehow essential for everything, not just those programs that really do require it.
Not entirely true, x86 was famously register starved meaning you had to spend a lot of time swapping things into and out of the general purpose registers. When AMD designed the 64 bit extensions, they doubled the number of registers to 16 total, meaning software could spend less time moving things around and more time actually doing something useful.
Systemd will forward to syslogd if you want it to so you can still use your standard tools to view the logs if you want.
If gimp pulls in systemd libs then a bug should be filed there. There is no technical requirement it needs to be that way according to the gnome folks.
During that "lengthly consultation process", nearly all of the for systemd was based on the advantages that systemd, as an init system, offer over competing init systems. In the months since Debian committed to systemd, Poettering has been increasingly vocal that he wants systemd to be more than an init system. That is why there is a renewed call for debate.
This is what I mean by reading things for yourself. I've been reading about his plans but you are mistaking the systemd init system with the overall collections of things he is working on. It's not as if the high speed DHCP daemon he has just written will end up in PID 1. His proposals so far is that there will be more optional daemons that either work better and at some point in the future I wouldn't be shocked if there were to be a debate over whether his addons should replace existing daemons but we aren't there yet.
You do not have to install gnome3 on Debian, I don't. As for systemd, I suggest looking through Debian's extensive documentation detailing why they chose systemd over the alternatives. At any rate the time to argue systemd was last year when Debian had a very lengthily consultation process. I also suggest looking up the systemd documentation for yourself considering the huge amount of FUD being spread about it and I find it telling that neither the Debian fork website nor the boycott systemd websites don't actually name any of their supporters.
1. OpenBSD supports laptops, specifically Thinkpads, better than any other operating system not called Windows. Suspend/resume works, instantly.
That's less of a good thing considering how nasty Lenovo is to work with. Not only did they continue locking their mini pcie port against "unauthorized" wifi cards, they have double downed on their customer hating behaviour by refusing to charge third party batteries. Since that was written, they seem to have moved the enforcement into the firmware.
Legacy? 5 years ago we had to interface with a bank who used XML with EBCDIC fields.
This is news to me. My main PC (debian jessie) has four cifs mounts on startup and they all come up with no trouble. The only systemd issue I've had so far was a minute and a half hang on startup that I couldn't spot but that was fixed by the latest debian update making the startup process actually tell me what it was doing. Turns out I had a swap entry in
I like Mac hardware a lot less when they disable hardware when they detect a non Apple OS
One way to make your old car run better is to look up the price of a new model.
