There are free software implementations of those but that's not really the point. Claiming the Chrome is free software is simply incorrect even though it is based on free software. If people used Chromium that would be fine but the problem is that they don't. The only reason why some people use Chromium is because some GNU/Linux distributions package it for them. The vast majority of Chrome users don't even know that Chromium exists. If Google really cared about free software they should remove the non-free bits and make it just free software.
How many hosting providers can you name that will install arbitrary certificates and run HTTPS for you without additional charges?
GoDaddy? (No)
FatCow? (No)
SiteGround? (No)
HostGator? (No)
BlueHost? (No)
DreamHost? (No)
They will generally offer self-signed HTTPS for a backend interface (e.g. one without your domain name in it). All of them want you to pay a fee for the service of offering HTTPS on your own virtual domain (regardless of who signs your certificate).
Not the same thing, wildcard helps in cases where multiple subdomains are being served by one server with only a single ip address. Since Let's Encrypt is currenly discussing wildcards, and its not looking good for them to actually support them, this would require servers to have an ip address per domain. If a server has more than 2 domains it is server, its COMPLETELY unreasonable.
It's not necessary to have an IP address per cert anymore since every browser has support for SNI nowadays.
You can run your own CA and install the CA certificate in you browser. For a private development site it's perfectly fine if it's only trusted by your browser.
They plan to offer a tool that does exactly that but absolutely don't have to use it. The plan is to have an API and nothing stops you from using that instead of the automation.
If my website just serves up public data that I don't care about the government seeing, you're going to disable new features on it anyway? Seems a bit extreme.
TLS can actually be used without encryption, the data is transfered in clear but you still get the authentication; which is actually something you want even if the data itself isn't secret.
If Let's Encrypt takes off, and it's fairly likely to do so given the sponsors they have (including Mozilla), you won't have to buy any certs at all. They will just be there automatically.
1. PulseAudio was good. The initial packaging in some distributions were however questionable.
2. Systemd is good, and the quality of it has nothing to do with PulseAudio.
I'm sure they'll agree that running a newer kernel that solves the problem temporarily until the distro has backported the fix is a better idea than running an ancient kernel which lacks the proper capabilities to support the userland.
Most users will run the combination of kernel and systemd which their GNU/Linux distribution ships. If your application does not work with that kernel then why don't you run an older distribution until the problem has been fixed? At the least running a newer kernel should be your goto solution before downgrading to an unsupported version.
Thats plenty clear, isnt it? As soond as kdbus is merged into kernel,
systemd will depend on it, and then if I need to go back to older kernel,
I have to downgrade systemd as well?
Nothing wrong with using Fedora in production. It depends on what you want. If you want stable and boring the no, don't use Fedora. But if you want to use the latest technology and is OK with rolling forward every 6-12 months then Fedora is actually a great OS to run in production. There's a reason why "software collections" is a big feature in RHEL, and that is that it's more and more common that you actually need newer versions than what's in your "enterprise" distribution. And if that's the case then using a newer distribution could actually be the right solution.
There are of course reasons why you wouldn't use Fedora. If you want a support contract or require certain certifications then use RHEL or something else.
They are not hidden, they have just moved to another place. The top-right corner is quite common nowadays to put these. Even Firefox has that now so it should be discoverable.
Slashdot Mirror
Ubuntu 14.04 uses Upstart.
You can read journal files too. It's like they are encrypted with a secret key.
Sounds like Apache is forking and running as a daemon, and you haven't told systemd to expect that behaviour.
it's in trying to resolve problems later on, when you'll find that systemd helps you obscure the source of the trouble instead of resolve it.
Obscured in what way?
By default Ubuntu uses dash as /bin/sh, but has /bin/bash as root's shell. Both can of course be changed by the user.
How about sudo -i?
There are free software implementations of those but that's not really the point. Claiming the Chrome is free software is simply incorrect even though it is based on free software. If people used Chromium that would be fine but the problem is that they don't. The only reason why some people use Chromium is because some GNU/Linux distributions package it for them. The vast majority of Chrome users don't even know that Chromium exists. If Google really cared about free software they should remove the non-free bits and make it just free software.
If it ever happened on a plane, then it means that the maintenance was intentionally skipped.
And that would of course never happen.
Especially since Firefox' certificates are hard-coded. Good luck removing untrustworthy CAs without recompiling the sourcecode.
That's easily done through the Certificate Manager.
It's going to take about five minutes before someone has made a blog post with the openssl commands you need to run. It will be no big deal.
A VPN will help in many cases, but it doesn't take away the need for true end-to-end encryption.
How many hosting providers can you name that will install arbitrary certificates and run HTTPS for you without additional charges? GoDaddy? (No) FatCow? (No) SiteGround? (No) HostGator? (No) BlueHost? (No) DreamHost? (No)
They will generally offer self-signed HTTPS for a backend interface (e.g. one without your domain name in it). All of them want you to pay a fee for the service of offering HTTPS on your own virtual domain (regardless of who signs your certificate).
I'm sure they will change their business model.
Not the same thing, wildcard helps in cases where multiple subdomains are being served by one server with only a single ip address. Since Let's Encrypt is currenly discussing wildcards, and its not looking good for them to actually support them, this would require servers to have an ip address per domain. If a server has more than 2 domains it is server, its COMPLETELY unreasonable.
It's not necessary to have an IP address per cert anymore since every browser has support for SNI nowadays.
You can run your own CA and install the CA certificate in you browser. For a private development site it's perfectly fine if it's only trusted by your browser.
They plan to offer a tool that does exactly that but absolutely don't have to use it. The plan is to have an API and nothing stops you from using that instead of the automation.
If my website just serves up public data that I don't care about the government seeing, you're going to disable new features on it anyway? Seems a bit extreme.
TLS can actually be used without encryption, the data is transfered in clear but you still get the authentication; which is actually something you want even if the data itself isn't secret.
More wildcard certs for me to buy.
If Let's Encrypt takes off, and it's fairly likely to do so given the sponsors they have (including Mozilla), you won't have to buy any certs at all. They will just be there automatically.
We failed to secure licenses from rights holders for the vast amount of music on the service.
But you still continued? Good plan there.
Probably GNOME. It's the default desktop in most major distributions.
1. PulseAudio was good. The initial packaging in some distributions were however questionable.
2. Systemd is good, and the quality of it has nothing to do with PulseAudio.
I'm sure they'll agree that running a newer kernel that solves the problem temporarily until the distro has backported the fix is a better idea than running an ancient kernel which lacks the proper capabilities to support the userland.
Most users will run the combination of kernel and systemd which their GNU/Linux distribution ships. If your application does not work with that kernel then why don't you run an older distribution until the problem has been fixed? At the least running a newer kernel should be your goto solution before downgrading to an unsupported version.
Thats plenty clear, isnt it? As soond as kdbus is merged into kernel, systemd will depend on it, and then if I need to go back to older kernel, I have to downgrade systemd as well?
Why do you downgrade your kernel?
Nothing wrong with using Fedora in production. It depends on what you want. If you want stable and boring the no, don't use Fedora. But if you want to use the latest technology and is OK with rolling forward every 6-12 months then Fedora is actually a great OS to run in production. There's a reason why "software collections" is a big feature in RHEL, and that is that it's more and more common that you actually need newer versions than what's in your "enterprise" distribution. And if that's the case then using a newer distribution could actually be the right solution. There are of course reasons why you wouldn't use Fedora. If you want a support contract or require certain certifications then use RHEL or something else.
They are not hidden, they have just moved to another place. The top-right corner is quite common nowadays to put these. Even Firefox has that now so it should be discoverable.