Even if you jail break the phone, is Apple going to let an app in their store that relies on it? No. What legitimate "pay" vendor is going to risk Apple's ire and legal department to provide an independent app that bypasses the Apple Store?
That is the best proof I've seen in this discussion.
Summary for the unwashed masses: Tim Cook is a big fat liar!
The first statement is valid. However, it is possible that Tim Cook isn't lying and instead just relaying what he believes to be the truth based on what he was told. Ignorance is not the same as lying, which requires intent to deceive.
What affects the 1%ers today will affect the 99%ers tomorrow. This was true for Electric Light and phones in cars, and will be true for imortality.
What about trickle down economics? While it has surely affected the 99-percenters, it was hardly in a positive way. Not everything that benefits the wealthy makes its way to the common person.
Maybe others can't/don't do this because there are very few locations that have the right conditions for wind/solar/geothermal production.
I think the architectural problems and the developers are interrelated. systemd started as an init system, like upstart. However, where upstart remained an init system, systemd has been really expanded into having its fingers in all sorts of system areas. That said, when I have to use systemd, and I have the option, I usually just re-compile it with the specific functionality required. Not all of it is bad, it just suffers from feature creep, or maybe feature over-reach.
I really am not a closet systemd advocate. I do contract work and very often systems are pre-defined that have systemd components in them. For instance, I will be doing a conversion for a firm to RH7. I don't have the option of telling the customer to not use systemd, instead, I have to convert their existing init scripts to work with it.
Is systemd my first choice, no, not at all. If anything, I am init agnostic. Ultimately, I will install/work with what my customer specs.
There is absolutely nothing simple here. Also, you are either lying directly or completely ignoring the given circumstances (i.e. lying by omission). No surprise, this behavior is typical for SystemD advocates. Unfortunately for you, some people are not that easy to fool.
If you re-read my posts, you will see that I am not a systemd advocate. I prefer upstart. As such, I am not a fan-boy of systemd and I am not fooled by it. That said, I think that if a different personality had developed it and it was being pushed by somebody other than RH, there wouldn't be so much animosity towards it.
Are you really comparing the emissions from a power station (outside of the city) to thousands of cars/vans/buses in the middle of the city? You do realise that it's far easier to clean pollution at a power station than it is at every single exhaust pipe, right? Do you want anyone to take you seriously?
Actually, that would be an interesting study. Obviously increasing the use of electric vehicles is going to put more demands on the power grid and require increased production at the plants. Most likely the demand to recharge will be a night, so solar is probably not an option, which leaves coal and natural gas (given the hydro-electric and nuclear is relatively fixed by external factors).
So the question to be solved is whether a large conversion from combustion engine vehicles (gas and diesel) to electric reduces emissions enough to offset the increased emissions from power generation? I would guess that the balance is in favor of electric, but to the best of my knowledge, that question has not answered by the scientific community.
Just start small with hybrid motors in the buses, enough to get them rolling again from their frequent stops (and red lights of course). If you just improved the fuel mileage a couple of miles per gallon, it would make a huge impact overall.
Actually, electric motors provide full torque instantly and would be a more efficient means of starting a bus rolling. The other thing to take into account, however, is starting up a diesel engine produces a lot of pollution. It would be a good idea to test the notion of frequent starts/stops versus continuous running as to which is better. If it turns out continuous running, then it may be as simple as using the engine to power a alternator and have the vehicle be diesel-electric, like trains. In passenger cars, it could be gasoline-electric. Such a scenario would allow the engine to run at it's most efficient speed to generate the electricity needed.
Actually, the use of more public transit vs cars will cut emissions regardless of whether the public transit is electric or not. Likewise, shipping more freight by rail instead of highway will, too. Of course industrial emissions far outweigh vehicular emissions but that's a whole different topic.
Alas, there isn't a will to do that, so the alternative is looking for less efficient ways to cut emissions, such as electric passenger cars. While better than nothing, the impact is infinitesimally small.
Lucrative is relative. Yes, COBOL programmers are in demand right now, because most of them have retired. Does that mean somebody just starting out should expend the resources and time to learn COBOL? Probably not, because the return on their personal investment would be less than if they spent it on more current/in-demand technologies. OTOH, a programmer that already has COBOL experience, can still find employment.
It's like buggy whips. As the buggy was replaced by the automobile, the demand for buggy whips declined. However, until horse buggies were completely gone, there was still a demand, albeit smaller than in its heyday, for buggy whips. If you were an experienced buggy whip maker, you could still find employment making buggy whips. However, it would not have been a field for a new apprentice to enter.
Likewise with COBOL and the other languages mentioned. There is still demand for programmers with that knowledge, but it isn't a growing field. At some point the cost to maintain the code will become higher than converting the code because the cost of COBOL programmers will be too great given the supply and demand curve. For those who currently are COBOL programmers, that bodes well, but not for somebody just entering software development.
BTW, I use COBOL in the above languages, but the statements apply to most long lasting programming languages, not just COBOL.
From the article "Rather than draw from a licensed collection of images, Defendant gathers these images by crawling as much of the Internet as it can, copying and indexing every image it finds, without regard to the copyright status of the images and without permission from copyright owners like Plaintiff,"
I wonder why Google wasn't charged, too? Isn't that how their image search works?
A sort of IDE for all the text based config files the way an IDE is a helper for the text code files of a programming language. (But NOT a binary that bypasses the text configs! Which is what systemd seems to be doing, if I've been reading this right.)
But you use a binary, even now to view the text files. Whether you us cat or less or vi or some other editor/viewer, human beings cannot read text files from a log without having to use a binary. That is because what we call text files are merely representational of a text file. Like a binary, though, they are just zeros and ones until some program interprets them for us.
Are you stupid? Modules compiled together are not a "modular" system in the UNIX philosophy at all. They are one program.
Except the separate systemd modules are all seperately functioning executables. That's why if you want to run gnome-shell, you can simply include the logind daemon from systemd along with whatever init system you want to use. Even if you choose to compile all of systemd, it only uses the daemons you turn on. How is that not modular?
Actually, systemd is all-or-nothing. If you let even a tiny bit in, countless things will break unless you take the whole POS. The developers are very keen on making sure of that.
That is simply false.
> the reality is systemd is a bunch of individual modules
I disagree. Technically you are correct, but the same modularity argument can be made for practically any piece of code bigger than "Hello World". However in practice systemd is shipped as a monolith. I just checked, and even on Genoo with its uber-flexible USE flags and compilation from source, you can't shut off individual features like logging, dhcp, ntp, etc. Most people just install the binaries.
No, systemd is not the end of the world. But it would be the end of running my machines the way I wish to - at least without spending more time and effort keeping it fenced in as you suggest.
Systemd has a configure system similar to the kernel. Like the kernel, where some distros use a "full" kernel and others use a stripped down version, it is up to the distro to decide what fits its need. The same is true with systemd. Take distros running late versions of gnome-shell, which requires the logind module of systemd, all they are including is logind, not all of systemd. Even Ubuntu is using logind with upstart and also sys init scripts.
Nobody is forcing a distro to adopt systemd. If the distro developers do and it impacts you, the complaint should be with the distro developers, not systemd. Maybe the developers have good reason for making the change. Most of them are community based, so it is doubtful that they are doing it just because Redhat is doing it (although Centos and Scientific would most likely change to maintain compatibility).
Even if your distro of choice does change, it shouldn't force you to stop running your machines the way you want too. You can freely mix systemd, upstart and init scripts, using whatever pieces you want for whatever need you have. That applies whether your system is a desktop, server, embedded or whatever.