I think the big issue is the potential to use this as a vector to introduce malware to the phone or PC the owner interfaces the device with. Not sure how practical that is.
The big issue will be that people will use this to display rude things on random people's armbands.
You want to bet that number subtracts the cost of their network build out from the profit margins? The bulk of the costs are the labour and equipment needed to run the fiber. Once the fiber is in place, upgrades are just a matter of swapping out the equipment at both ends and the costs will drop sharply.
They are making money, it's just that internet is less of a profit center than wireless so they would rather put the money where they can make the higher profit.
Your plan falls apart when you have large groups of people who are willing to believe literally anything about some group they don't like and refuse to accept any evidence that they are wrong.
The number of people who believe Obama will bring in Sharia law or has the national guard preparing internment camps is outright staggering.
That's pretty interesting considering it was designed for servers to begin with. Servers are far more likely to have weird dependencies on boot such as root drive over the network or worse yet, boot drive over clustered file system over the network and where Debian said they are losing share due to not being able to support some of the larger server configurations.
For the embedded space, it either uses less memory than the current setup, or you are rolling your own init and don't care about systemd at all.
PfSense is a must if you are running ESXi topologies.
SystemD hatred is pretty simple. A large amount of untested, potentially unsecure, unaudited code was placed at the core of Linux's userland, and forced on end users (enterprise IT shops) without any real testing or feedback by end users.
RedHat has bet the farm on SystemD... if/when it has security issues (it has network connections, so in theory, it can be remote rooted), it can cause a mass flight from RHEL and downstreams. The gain? Little to none, from the end user point of view.
I am keeping fingers crossed, and hoping someone forks the cash for an audit of the code... Oracle and Microsoft are waiting in the wings for mainstream Linux distros to fall on their face if something does break.
You do realize that most of the systemd addon daemons run
1. As a completely separate process
2. With the minimum permissions need to do their job.
3. The stuff with network connections are definitely optional..
I know they have some network things that they optimized for containers but they don't seem general purpose so I don't run any of them on the servers I'm testing systemd on. So far the only actual Systemd issue I've had is that it screws up pulse audio on one of my machines (works fine on the laptop screws up on my desktop).
Plenty of performance and memory, never any issues. It makes me wonder why more router manufacturers don't use Linux or BSD derivatives for their firmware instead of writing garbage in-house.
Mainly because the market is very price sensitive and as a result routers tend to use some slow SOC with a minimal amount of RAM because it costs less. Linux or BSD wouldn't do you much good if every time someone fires up bittorrent, the NAT table fills because there just isn't enough RAM to handle it all. It has only been recently that I've seen routers with a decent amount of ram and even then that has been in the $150+ range while most people I know refer to spend $30 to $40.
A few years back my friend went to get his BMW from my garage where he had left it for the winter only to find a flat tire waiting. I thought "no problem" we can just use the spare just as my father taught me. We pull the jack out that came with the car and attempted to jack the car up but the jack actually started to collapse under the weight of the car. At that point we gave up and called CAA and when the guy arrives says "why did you guys try to do this yourselves?" It seems the jack was mostly decorative.
Throw in modern cars with diagnostic readouts proprietary to the car and you find a car that is simply not designed to be repaired by anyone other than the dealership so don't blame training or our generation for the problem.
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.
Your files are now being encrypted and thrown into the bit bucket. EOF
