Comment Re:worse than crapware (Score 1) 427
The faster people realize this the better this world will become.
How I stopped worrying and learned to love the creeps.
The faster people realize this the better this world will become.
How I stopped worrying and learned to love the creeps.
Also, OEM/carrier crapware was far more likely to do funky stuff in the background without the user's knowledge/approval than GMS.
I don't have much experience with OEM/carrier crapware, but it must be pretty extreme if people are running to Google to get away from funky stuff happening in the background. GMS is in constant communication with Google and runs with root access and the ability to do/read/install anything without the user's knowledge/approval.
Most people may install CM/AOSP to subsequently install gapps, but I went that way to get Google's creepy feelers out of my phone.
...and the grid network has gone to hell.
I'm glad that it's not just me who thinks so. I'm installing a PV setup at home just to have reliable electric service.
It's that we trust 400 of them by default in the first place, and any one of them should be easy enough to subvert by a sufficiently powerful nation-state.
Some of them are directly run by nation-states.
A decent stepping stone would be to allow multiple CA signatures on a certificate. Then, a user can decide how much they trust a certificate based on which CAs trust that certificate. As an added bonus, and verified through DANE or the like, it would be necessary to compromise multiple CAs in order to present a forged certificate. This moves us toward the big web of trust that you propose.
Once this is set up, we can start pruning the massive implicitly trusted root CA list and bring a little sanity to who we need to "trust". If you haven't done so, take a look a the lists sometime. Your computer/browser completely trust any certificate signed by any one of those foreign governments or unrecognizable organizations. How secure is that?
New incandescents and halogen bulbs have markedly short lifespans, too. Most of the old incandescents in my house that are many years (to decades) old are stamped "USA". The older ones that fail are stamped "Mexico" and the newest ones made in China rarely last more than a few months. This generally tracks the age of the bulbs as manufacturing was moved and costs were cut.
If you go to the hardware store, you'll see new halogen bulbs bragging about how they'll "Last 1 Year!!". Sometimes they do, while the ten year old bulbs next to them keep going. I'm hoping that the LED bulbs that I'm replacing them with last longer.
All of the networking functions are performed by native tools, but I'm not sure of the details. As a fingers-crossed-with-rescue-media-ready experiment, OS X seems to run normally with all of the shells removed (except the terminal and my own scripts, of course).
"Gimme gimme gimme. Mine mine mine!!!" -populous
To be fair, they learned it from watching the ruling class who have already taken most of the pie and left the scraps for the hoi polloi to fight over.
I just wished they would make it impossible to use terminals at all anymore so we would never be bothered by such garbage again. I guess Gnome is not as awesome as they thought they were since it is still (technically) possible to fire up a terminal and start, EGAD!, typing. What an archaic concept.
Don't worry. In Gnome 3.swipeup.swipeleft, the terminal will be replaced by a multitouch paint program where you enter all of your commands from an arcane collection of gestures! Four-finger-left, three-finger-pinch, tap for the win!
The (ancient) version of bash that ships with OS X appears vulnerable. Luckily, as a remote exploit, only authenticated ssh sessions and cgi scripts etc expose it, so most single user workstations (of all OSs) should be safe.
If this is a bash exploit, and not a Linux exploit, why all of the focus on Linux in the article? I use bash on many different OSs.
Nice, but not going to happen. Any processing that can be done locally can be done server-side. The hit to the user experience caused by latency and data usage is well worth the data available for mining and the built-in obsolescence from server dependence.
Those of us who build and maintain large-scale Linux infrastructures would be happy to see a highly specific, highly stable mainstream distro that had no desktop package or dependency support whatsoever, so was not beholden to architectural changes made due to desktop package requirements.
He's talking about systemd. That's the only real architectural change that affects the server installs of many desktop/server distros. I don't know why he couldn't just come out and say it, though.
As you say, Gentoo or Slackware will still let you make "thin" servers if you feel the need for that.
That's where you find the Wisdom Chits necessary to advance your civilization.
(Wow . . . no hit on the correct reference ten pages into a Google search.)
I agree and am happy to see this fork. As unpopular as it may make me, I actually like the initd functionality of systemd. I'm fine with using and writing the old init scripts, but systemd unit files are simple, concise, and powerful enough for my needs.
On the other hand, I find the kitchen-sink feature creep of systemd absolutely repulsive. Cramming all of that functionality into PID 1 as a unwieldy monolith seems like such a deeply flawed exercise. Uselessd seems like a perfect replacement for systemd: all of the benefits and none/less of the cruft.
It is clear that the individual who persecutes a man, his brother, because he is not of the same opinion, is a monster. - Voltaire