Agreed. I've used various Bluetooth headsets and car adapters and *none* of them seem to hold a candle to a regular audio cable.
For in-home speakers, I have a set (actually, more than a set... almost 5) old XtremeMac TangoAir speakers that use Apple's AirPlay for transmission, and the encoding that's done there is oodles better than even the best Bluetooth speaker quality I've heard.
And yeah, anyone who cared about audio quality enough to care about this was probably ripping at 320kbps 15 years ago. I've been slowly going through my CD collection upgrading them to ALAC lossless simply because disk space is beyond not an issue any more. I can't say I can hear the difference on most tracks, but definitely can't on a Bluetooth device.
We've had that discussion at work, with the pro-RHEL arguing that since prod machines would be RHEL, dev and test machines should be too in order to avoid bad surprises down the road. We even considered having the full-blown hardening done already in dev to make sure our friends the developers didn't do something that wouldn't work in prod. Turns out this approach causes a huge dip in productivity, especially when chasing those mysterious selinux denials. Exciting the first few times because you feel like you're "doing the rigth thing" but soon enough you get a nosebleed just by typing semanage. Ansible helps a lot, but only once you've got the right recipe.
Have you considered SELinux permissive everywhere in dev, with sign-off on QA? Depending on your app, of course, SELinux really does get easier once you get more and more used to it. audit2allow really is your friend... A day of letting your app run in permissive mode, then pipe the audit log for it through the policy maker and factor its needs into a coherent (and meaningful) policy, then just bump that as needed.
semanage can be a pain for booleans, but again it's mostly up-front work and then catching what breaks going forward.
Going back to the topic though, is there a significant difference between RHEL and CentOS in this regard? The vast majority of boxes I run on have been CentOS, but I typically dev on a RHEL in full SELinux enforcing and I haven't really noticed an issue except when there's a delay in a policy making it to the CentOS repos.
and run systemd as Just Another Daemon, akin to xinetd, supervise, or your cluster management software
This is dangerous, as systemd expects to be PID 1. If it expects to be the root of userspace and isn't, there will probably be complications.
It's better to build a distro without systemd entirely than to try to hack it into pieces without careful planning.
I'm not saying it's impossible, but it will be damn hard if it can be done. Already, the first attempt (by uselessd) has been abandoned.
Among the many other issues with systemd, this sticks out.
Literally the only thing unique about PID 1 as such (besides obviously being the first process launched) is that it gets ownership of double-forked / parentless processes and related signaling. There should be no reason that systemd couldn't function as a standard sub-process, albeit with the reduced functionality of not being able to track processes that intentionally escape.
The general unwillingness to gracefully fall back to reduced functionality when not all the Kool-Aid has been drunken is a fine example of EEE principles in action.
I think you summarize the problem pretty well. Systemd is a desktop solution for people who essentially want a Macbook.
What would be great? Having systemd only in specialized desktop distributions. Not on servers and not on desktop for power users. Even better: systemd should be a distribution itself, not be a part of other distributions. And it would also have the exclusivity of pulseaudio.
That's exactly it. If this were a GNOME or *DE toolkit focused on providing low level services for desktop environments, it'd be totally fine; well -- more accurately -- I wouldn't care. The problem is that by taking over PID 1 and forcing a paradigm shift or replacement of any number of other utilities, it's in the "core" instead of the desktop. It didn't need to be that way, and shouldn't have been. And if it *had* to, then it should have been a component of a new, forked, modern desktop distribution.
Instead it sucked up Fedora under subterfuge ("It'll be just like the upstart switch except 5.6% awesomer!") and Debian thanks to the bandwagon effect breaking a tie.
The best battery optimization would be dictating that manufacturers shall provide adequate batteries on their devices if they want access to the Google infrastructure. I, personally, am sick and tired of hearing people whine about battery life on their 3-micron thick devices with 2000mAh batteries.
Have they fixed the rather major defect they introduced by forcing an unconfigurable doze on us all?
Any application which requires the device to remain active (ie. safety applications like marine anchor and AIS alarms) are not functional on Android 6.0+. Even if you add applications to the exception list, they'll still be suspended, and woken only every 15 minutes while dozing.
A simple "do not EVER interfere with this process under any circumstances" option would resolve it, and to be honest it's quite shocking it was ommitted.
CentOS and RHEL are functionally identical, except for the 12-36h delay in updates and the specifics of update channel management.
That was one of the points I (GP) was trying to make... Looking at just official RHEL subscription numbers doesn't take into account the broader "RedHat-led ecosystem" of releases which are broadly (if not ABI) compatible.
Many orgs pay for RHEL licenses on mission-critical boxes and a sample of their own servers, then run CentOS on fleet boxes. OTOH, people working in densely virtualized environments might consider the hypervisors the critical ones and be willing to pay for them, getting unlimited VM guest licenses for free with it.
They are both scummy companies and shouldn't be trusted. It's Nexus or nothing.
Not sure why you're trusting Google here. Are you disassembling the binaries in your Android operating system*? If not, then you have no idea what Google's doing there to use the sensors you've got strapped to your body 24/7. The only safe smartphone is one that doesn't have sensors at all, and has a physically removable antenna and battery or physical off switches for both.
(*And face it, no body is. Even if, in principle, it's possible, no one is *actually* doing it before use except security researchers.)
Going back to the article, though... I'm surprised LG doesn't have a larger share of the market -- and isn't making more in the way of profit. I've been a fan of their phones since the EnV chiclet keyboard days, up through the touch feature phones, and have had the G2, G3, and G5. They've all for the most part been extremely reliable phones with good feature sets and a camera that's second-to-none at the price point for low light conditions.
There are systemd-free distros of Linux, you know. I can pretty confidently state that it will remain that way unless systemd should start to integrate itself into the kernel.
Well, yes... Most importantly RHEL6 / CentOS6. Those of us using Linux in business/enterprise settings are mostly running that, and that's mostly what we care about. The time limit on that is what we're sweating.
RedHat (Inc.) seems to be undervaluing its Good Will in terms of building an enterprise platform that goes well beyond RHEL subscriptions. EL users don't care about most of the systemd "feature" set (with the possible exception of easy(-ier) cgroup management), since most of the rest either doesn't apply or attempts to re-solve and already mostly-solved problem (eg, service monitoring and restart scripts). The cost is using less mature, less modular, less tested code with more common failure points, which might cover 80% of your needs but makes the other 20% of system customization really, really difficult, because apparently shell scripting is a Sin now.
Oh, and most of your config management that worked pretty similarly between EL5 and EL6 has a *lot* more of a delta to work with EL7.
"Forking Fedora" doesn't seem like it will happen, even though there are fewer and fewer non Kool-Aid drinkers there who think keeping your options open is a good thing.
Do you know what I'd like for EL8? Fork EL6, update all the non-daemon RPM versions to their current Fedora level, and run systemd as Just Another Daemon, akin to xinetd, supervise, or your cluster management software.
We get more reliable and more deterministic startup and shutdown process using the previous initscripts toolset and regular
The amount of time between slipping on the peel and landing on the pavement is precisely 1 bananosecond.