Comment Re:Don't be Evil (Score 2) 629
The hardware provider should push Android 5.0, not update legacy releases.
The hardware provider should push Android 5.0, not update legacy releases.
Then I guess he's not working on OpenBSD.
http://www.openbsd.org/errata5...
He has not been involved with Tumblr since ca 2010 if I remember correctly.
That's not how it works. You subscribe to "Netflix," not to specific content.
Our company runs our own servers; we run Ubuntu Linux. Our web sites are PHP. All I know is to run apt-get every Sunday and Ubuntu can update whatever it wants to. These are in-company web sites with login user names and passwords. No e-commerce involved; no public involved.
In case you ever run a public Ubuntu-based server make sure that you never install packages from the universe or multiverse components of the package archive. They are not updated by the Ubuntu security team and can therefore include unpatched vulnerabilities, which include a large number of php5 packages.
Why aren't there "long-term support versions" similar to what Ubuntu offers? Only security flaws are patched in such versions.
Ubuntu only supports a handful of packages, specifically those in the main and restricted sections of the package archive. This includes the main php5 package but a large number of modules are kept in universe and are not supported at all.
However, I realize patching security flaws can break existing software also, but if you only patch security flaws rather than add and change features for the line, the magnitude of problems from updates would be smaller.
It depends on the vulnerability. I had things break when the bash vulnerability was patched some time ago. There is no solution other than test that things work before you apply the update.
Bah, an engineer is someone that runs a locomotive.
Or use a distribution which provides updated and supported versions of the tools you need. Red Hat for example provides a base version of PHP if you want something which is stable throughout the entire life cycle of the operating system, but they also provide software collections with a shorter 18 month life cycle if you want a newer version of say PHP.
Slashdot is large enough for everyone. You don't have to be interested in every story.
Exactly.
I do not know the answer for the Debian, but if you did RTFA, you would notice that it is precisely what the Devuan is doing: creating and packaging software which provide the interface of systemd services without the systemd itself.
Yes, that's what they are doing.
The (retorical) question which I have already asked on difference occasions here is whether the Debian is a good place to do such development.
One strong undertone from the CTTE's init system selection debate was that Debian doesn't want to do the development and wants to maximize the reuse of the code from the other distros. This turned into a weird attitude when systemd vs. upstart was evaluated. The upstart devs and maintainers have committed themselves to implement whatever Debian needs. The systemd devs and maintainers committed to literally to nothing, basically saying "if it is good for Fedora is should do the job for Debian too; no Debian specific patches are going to be accepted even into the Debian systemd package". And that was later respun by a couple of CTTE members as "upstart still needs development while systemd doesn't".
That is also why I raise the question about changes to the Debian organization in Devuan: How could Devuan be more software developer friendlier? At the moment the barrier to entry is very high, leaving developers at mercy of the respective Debian packager. Or leaving the developer basically out if it has something to do with the low-level stuff like init system.
You're talking about Debian and Devuan like it's two monolithic organizations. It's not. It's people. And and if you want "Debian" to do something then real human Debian developers will have to do the job. It doesn't matter what any committee decides if no one is interested in actually doing the work.
The Devuan developers are obviously up for the task. That's great. They do what they want to do. It's just too bad that they for whatever reason couldn't do it in Debian. I don't blame them. It takes an arm and a leg to get into Debian nowdays, so if it's easier for them to create a fork then maybe that says something about the Debian project too.
"who is going to make all these packages compatible with sysv init"
Exactly. Did someone step up within Debian to do it?
And GNU/Linux is not UNIX.
Choice is not a matter of just pressing a button and have it magically appear. Someone has to actually maintain it. The Devuan developers think that they can do that. If so then that's great. It's sad that they don't think that they can do the same thing within Debian though I understand their reasoning. It takes a lot of time and effort to get into Debian and they want to be more pragmatic.
NetworkManager has a command line interface. Two actually, a cli tool and one based on curses.
Software production is assumed to be a line function, but it is run like a staff function. -- Paul Licker
