Here is a hint: computer "neural networks" are nothing like how brain neurons work. The fact that people bleat on about "neural networks" just shows that they don't know how AI works. NN are a dead end.
They don't need to be like how brains work at the symbol organizational level, at least not any more. We can get there by just throwing interconnected data at it now. Sure, it would be more efficient to continue building that, but we're at the point where we're just a few Moore's Law updates away from being able to represent it at the synapse level without understanding the higher processing at all.
In some ways, that's even scarier. We'll have AI and not understand how it works any more than how we understand the brain works now.
We are no closer to AI now than we were 70 years ago. All we have now is better dB lookups. *yawn*. Call me when someone creates an approach that has a possibility of creating AI.
We can train neural networks far, far faster than we used to be able to. But outside of that, yeah, nothing except standard evolutionary improvements. Eventually standard improvements will be enough, but we won't notice that happening. 3D printing is starting to move on from plastic and we'll get a nice boost out of that far sooner than any AI improvements coming down the stream.
^ This. Vastly increased networking and data collection makes some of the previous growth requirements predictions meaningless. With enough data coming in (sensory-level), you don't need strong AI algorithms, you just need a neural network that can be bootstrapped.
Alphabet has clearly demonstrated the rapidity at with AI can be developed if you just shove data at it. Who need to sit there training a voice recognition product for years when you can just turn on the microphone in Android and have 100M people in the US providing voice samples all day long? There's petabytes of data out there waiting to be analyzed. Eventually, you don't need to hack your way to AI programmatically, when you can "brute force" your way to it by shoving it the data we're all providing the AI companies with on a daily basis.
And let's be honest; that's what Alphabet is: an AI company. That's the future of information.
Meh, they were talking about neural nets back when I was in school. If it has only progressed from Chess to Go in that time, then it has a long way to go.
That's pretty myopic.
Facebook's AI can predict when people are going to start dating with 96% accuracy, which is better that most human friends will be able to do. Google Now aggregates every bit of data Alphabet has on you and can predict where you're going to go tomorrow evening, when, who you'll be with, and probably what you'll order to eat there. Facebook knows how you're feeling and will display ads to you appropriately. These are generic neural nets, not specialized. And when you shove petabytes of data in, it really doesn't matter. Finding correlations between one set of data is limited only by how much you can throw at it now.
As predicted, the Singularity is Nigh. Furthermore, we're approaching the Singularity faster and faster due to the increased amount of interconnectivity nowadays. Today, you can probably re-ingest the entire useful volume of data in the CyC project just by aggregating Android microphone and location/sensor data at Alphabet.
* systemd-logind will now by default terminate user processes that are
part of the user session scope unit (session-XX.scope) when the user
logs out. This behavior is controlled by the KillUserProcesses=
setting in logind.conf, and the previous default of "no" is now
changed to "yes". This means that user sessions will be properly
cleaned up after, but additional steps are necessary to allow
intentionally long-running processes to survive logout.
While the user is logged in at least once, user@.service is running,
and any service that should survive the end of any individual login
session can be started at a user service or scope using systemd-run.
systemd-run(1) man page has been extended with an example which shows
how to run screen in a scope unit underneath user@.service. The same
command works for tmux.
After the user logs out of all sessions, user@.service will be
terminated too, by default, unless the user has "lingering" enabled.
To effectively allow users to run long-term tasks even if they are
logged out, lingering must be enabled for them. See loginctl(1) for
details. The default polkit policy was modified to allow users to
set lingering for themselves without authentication.
Previous defaults can be restored at compile time by the
--without-kill-user-processes option to "configure".
The article is wrong. Systemd didn't change anything. Debian's config for systemd changed a default. Either option is a problem for people. But its not unreasonable to assume that users that want to have long running process know more about their systems and thus how to change them than users who want everything to stop when they logout. The change in default makes sense, and systemd is doing the right thing here.
What's a pain is the disruption caused by transitioning from a non-sensible default to a sensible default.
Your comment is wrong.
Debian didn't *intentionally* change the default. Systemd did. Debian failed to catch/care/notice/revert the change. This happened with Fedora as well (well, rawhide, Fedora's rolling unstable branch).
And in what way does this new mechanism "enhance security"? Running something in the background after you log out doesn't give you any more privileges than if you remained logged in.
I get people being angry about Systemd, change is hard on people and giving up behaviours/knowledge that the community has prided as a point of recognition feels like losing a culture divergence from the Unix philosophy. Unfortunately they're looking at it from the wrong perspective.
The proper perspective is to understand that Systemd is a significant conceptual step towards targeting the enterprise with Linux. This change has made it so Linux effectively now has a centrally manageable remote process control system built in by default. This is an additional level of control over user space processes, which at the enterprise level, is a very valuable feature. Effectively the *nix version of Microsofts "Applocker" in an environment where a user often operates at higher levels of permissions. That's how enterprises operate their networks and a significant step up in securing Linux from that point of view.
Don't dare say sudo in response, great single system low user count idea, but again I'm talking about the enterprise level, hundreds of thousands of servers, desktops and accounts.
This might make sense if Enterprises were adopting EL7 en masse. They're not. All the fancy newfangled features are meaningless if the system is no longer trustable or reliable, or can't reliably (and deterministically!) boot. And the vast majority of the complexity isn't around resource management, it's dealing with events occurring because Lennart moved his laptop from one coffee shop to another. Enterprises *that* focused on security that some of the new features might be worth it for have already found solutions on EL6 for the most part.
Individually, there are some neat features. Collectively, systemd is a complete and total disaster being guided by a loon with delusions of grandeur who doesn't give a F about anything besides his use case. Enterprise people have seen that kind of thing before and know how unreliable those projects end up being.
THAT'S EXACTLY THE POINT. Need something/sbin/init didn't already do? Have it launch another, specialized service manager of your choosing. Have it launch several! Original inetd, xinetd, crond, supervise/daemontools, linux-ha / heartbeat,... plenty of options. Have it integrate with other systems however you need it to. That's why you're an administrator.
The problem is that this results in race conditions and "who watches the watchdog" type of scenarios. Plus if the intermediate supervisor dies for some reason the children with then be reparented to PID1, ie the basic simple init, and the restarted supervisor would then lose sight of them properly (ie no longer a parent so can't wait() on them).
You're correct in that it can cause race conditions, but you're not giving sufficient weight to the fact that admins have heterogenous solutions for those. Who watches the watcher? Maybe a cron job. Maybe puppet. Maybe another service. Maybe monit or any other monitoring system you have. An administrator should look at their own likely failure states and automate accordingly.
How many times has xinetd crashed on you in the last 10 years? How often does daemontools or supervise crash on you? These types of servers are single-purpose designed and have well tested code. Small, simple, focused programs that do one thing and one thing well precisely to reduce the problems that can result./sbin/init forking a shell and forking a small bit of C code (eg, svscan) with a monitor running via cron (and maybe a second monitor running persistently as a distinct service) is oodles more auditable, reliable, and understandable than a monoculture of systemd attempting to be responsible for everything.
Fedora can't even do that any more... Fedora IS the upstream and there's basically no one who can push back at the Fedora level for a dumb upstream systemd decision
Note quite. Fedora is not the upstream for systemd, systemd is its own upstream and frankly has been driven more by CoreOS needs than Fedora ones recently (with the whole resolved and networkd stuff which are not used in Fedora since we use NetworkManager). Check the number of patches in the F24 spec for instance. The discussion is ongoing at the moment and this will become a F25 change that gets debated by FESCO. It's likely that the Server and Workstation product, for instance, may split in their behaviours here given the different use cases.
Be fair. That entirely was the situation. It's a neat sophist trick, wearing the upstream hat and the downstream hat and claiming the other guy with the hat is tying your hands. (Not you personally, the collective "you".) https://bugzilla.redhat.com/show_bug.cgi?id=1170765#c58 The simple fact is that huge bits of what once had been Fedora-level policy is now more or less handled by "upstream" and there's continual pressure to not deviate from upstream. Anyone with any experience in any sort of team politics should be familiar with that.
systemd was and is a power grab, plain and simple
No it is an attempt to fix our broken init landscape (it's notable that no one wanted to keep sysvinit as the default in the Debian CTTE decision) and solved not only the sysvinit problems but the upstart ones as well.
Go back and look at any of the small decisions over time from Fedora 15 onward made to make it extremely inconvenient to use any other init system anywhere in the ecosystem.
Again and again I've heard people like you suggest that Slackware is a replacement for a modern mainstream distro like Debian. Others suggest Gentoo.
Well, the reality is that neither is sufficient.
Slackware is, to put it politely, very primitive. While simplicity is a good thing, Slackware takes it to the point where it becomes a liability.
When using Debian, it's possible to get a full-featured desktop or server set up with very little effort, and this can be done quickly. Thanks to sensible defaults and a practical installer, manual configuration is kept to a minimum.
Frankly, what we need even more than Devuan is a fork and re-structuring of the RedHat ecosystem. Unlike.deb-land where the more dynamic Ubuntu is a downstream of the stabler Debian, the "upstream" of RPM world is the bleeding edge Fedora where this crap began with, not the more-enterprise-stable RHEL.
The unfortunately-named CentOS ("Community ENTerprise OS") is an intended binary-compatible rebuild of RHEL, so it really doesn't have the freedom to change anything at all and remain within its goals (even before it became part of RedHat). What's needed is a sane, more stable fork of Fedora.
It could be done... Start with CentOS 6 as a baseline, and bring this up to date with CentOS/RHEL7 tech (kernel, glibc etc.) using Scientific Linux 7 as a concept for rebuilding. Bring in stability features, while leaving out as a requirement what's generally a poor fit for a server, such as systemd as/sbin/init, NetworkManager, etc. It doesn't mean they're not there, but they're not forced. systemd can still run, it just isn't PID1... It's a service launched via script just like any other service manager (such as xinetd).
From there, build a server-quality distro that's broadly (generationally) compatible with the major release of RHEL, but is free to not do the stupid stuff.
RPM-world needs and deserves a new, server-class RPM-based distribution.
I am yet to see a use case presented that the existing initd system cannot handle if you take the time to understand how to use it properly.
Really? Because I can't remember the last time I ran a Linux system where init didn't launch some other daemon with the express purpose of handling all the stuff it wasn't able to regardless of how well you understood it.
Woosh.
THAT'S EXACTLY THE POINT. Need something/sbin/init didn't already do? Have it launch another, specialized service manager of your choosing. Have it launch several! Original inetd, xinetd, crond, supervise/daemontools, linux-ha / heartbeat,... plenty of options. Have it integrate with other systems however you need it to. That's why you're an administrator.
The point is: none of those other daemons pre-supposed that they were the only ones, pushed out other ways of launching services, or needed to exist as PID 1 (of which there can obviously be only one on a given running system)./sbin/init was kept simple and agnostic.
As now I am being told that I'll have to make modifications to the way somethings that have worked for years.
For that you can blame the maintainers of your distribution. After all they are the ones who rolled out an update to you with a default blindly set from upstream despite it not being compatible with the way the rest of their system runs.
There's blame to go around. The specific, stated goal of the systemd developers is to make it harder and harder to use configurations and setting that they do not approve of. Through a series of what they call "gentle pushes", they want to unify Linux userland across the distros. The history of the last 5 years is that the default will soon become mandatory.
But yes, fail on the Debain devs for not standing up for the distribution. (Fedora can't even do that any more... Fedora IS the upstream and there's basically no one who can push back at the Fedora level for a dumb upstream systemd decision. Debian... don't be Fedora.)
If you want systemd so badly - why don't you just make it a service of initd?
The irony of recommending the exact thing that systemd was made to avoid is unfortunately lost on the fact that this fundamentally doesn't work if any of systemd's functionality is to work at all.
Why are you guys, who cannot demonstrate you know any better, subjecting everyone to use this?
Who guys? The guys who invented cgroups? The guys who wrote kernel support for it? The guys who have put effort into replacing init over the years? The guys who compile a distribution with software of their choice to "best suit their users"? The guys who don't chose sane configuration options? Who is subjecting you to use something against your will?
systemd was and is a power grab, plain and simple. Grab as much land as you can, make it "too convenient" to not give in to additional power requests on the grounds that it makes your own life easier, and suddenly the frog is quite boiled and you're trapped. Go back and look at any of the small decisions over time from Fedora 15 onward made to make it extremely inconvenient to use any other init system anywhere in the ecosystem. From hard dependencies to banning the inclusion of any sysvinit scripts (even as an option!) in RPMs in Fedora, which serves as the de-facto upstream for basically all RPM-based distributions. People who didn't want to use systemd absolutely were being subjected to it against our will. To claim otherwise is ludicrous.
The vast majority of systemd AS IT WAS ORIGINALLY PROPOSED does not need to function as PID1, because it forks other things from it. The only thing special about PID1 is that that's where parentless processes go. A systemd binary can launch other processes beneath it and remain in complete control over them for the vast majority o
They log in remotely via SSH running on macbooks...
No, it's actually the opposite, which is quite a bit worse.
They only dogfood their shit on their [macbooks]... And the occasional virtualized cloud container bollocks. In short, they're thinking ONLY in terms of a Developer, and a specific type of systems administration that basically consists of hard-coding their administrative decisions into code. Well, bully for them. Congrats on making their own specific, unique use cases work better for them. Unfortunately, they're so full of themselves they don't think any other use cases matter. If you're not doing it this way, You're Wrong... no matter what you've been doing previously.
Did you install systemd from source? No, you install it from your distribution. Are they going to install with the feature on or off? Why are you suddenly spurned by the default behaviour of something trivially overwritten becoming the default? If its a dumb change, all distro providers will ship it off by default and nothing of value was lost.
Their stated goal is to subsume the the distro's decision-making process by continnually nudging them to their preferred defaults. "Harder and harder to use things the wrong way", IIRC.
the reality can be seen in those distros and operating systems that do not use SystemD and are not "creaking"
So tell me, just how do you keep track of a started service, to verify that it is indeed running and to shut it down cleanly? If you have any better solution than pidfiles, I'd love to hear it.
And yes, that is one of the things that systemd solves. I may not always agree with the default settings chosen, but systemd exists because there are good technical reasons for something like systemd to exist, and the systemd devs are apparently the only ones who don't stop at whining but actually code. So long as the haters do nothing but whine, you will have to put up with Pottering's insights and foibles.
Wrong. pid files and subsys locking worked and continue to work fine for the vast majority of cases. CentOS 6 / RHEL 6 is still super-widely deployed and many enterprise shops are delaying moving to EL7 (when they otherwise might be right around now) specifically because of systemd and a few other changes. Somehow, we're managing to run a modern system without using systemd... Crazy, I know!
For those that *do* need a service manager, there have already been solutions written for it. I use daemontools personally, but other people have different tools. The point is: Almost nothing that systemd does with regards to service launching couldn't be (and isn't already) done with some combination of "normal init scripts", xinetd, and daemontools. It's one true nifty feature in that area is automatic cgroups management, but frankly that feature alone is nowhere near worth the hassle of dealing with all of the other crap they're doing.
But was this the systemd developers at fault or the person who build the installation package? It sounds more like a lack of configuration with a.deb.
The systemd developers' stated goal is to "provide gentle nudges" continually to synchronize any downstream users (in this case, meaning distros and users) to their view of what the proper use is; and this has been matched over the years by their actions.
Furthermore, on the Fedora side the Fedora devs have basically abdicated formerly-distro-level decisions like that to "well, upstream has made this change and we want to stay in sync with upstream."
FWIW, I've only found one quote by Lennart Poettering about the entire thing (source):
I am not sure I follow. Note that user@.service is already reference counted by the login sessions around. i.e. it is started before the first user session of a specific user is created, and stopped when the last user session ends. I don't follow why that behaviour is not sufficient?
Lennart seems to have learned by now to be careful what he says in public, so I don't expect him to call anyone a moron here.
No, there's a similar debate blowing up on the Fedora list as well, it's just that there's hardly anyone left with the energy to fight the cabal any more.
In my view it was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout. It has been discussed for ages now among many OS people, that this should possible but certainly not be the default, but nobody dared so far to flip the switch to turn it from a default to an option. Not cleaning up user sessions after logout is not only ugly and somewhat hackish but also a security problem.
...
I am pretty sure we should consider it our duty as Fedora developers to improve the Linux platform, and I am pretty sure that properly cleaning up processes on logout is a step towards that, not against it.
You realize that the AMP pages are essentially static, right? The required styles (if you read Google's AMP tutorial) supply some webkit animation bullshit, but there's nothing really "interactive" about the AMP webpages that you see atop Google News now. In fact, what you're getting isn't actually much different from what you'd find in RSS (just via some extra json crud instead of straight XML like the content basically already is). Everything else in AMP (like amp-ad) is just reinventing the wheel badly.
If I read you right, Google Reader has returned from the dead in the form of the worst XSLT you've ever seen... and more spying.
If "using more closed source software" means the freedesktop.org guys and/or their target audience moves over to shiny new Mac Books and leaves the Linux ecosystem alone, I'm all for it.
Not just systemd, but a lot of the other work that has come out of the Linux-on-the-Desktop-is-right-around-the-corner community has destabilized lots of working server installations. Maybe once they can be convinced that the future of the App crowd is back in the closed source hosted or closed source ecosystem area (hint: it is), we can start to wrest control back and begin picking up the pieces.
The RAZR was good, but for me the most iconic phone has been the Nokia 7110. The thrill of pressing the slide release button was simply unrivalled. The almost dangerous speed that the spring loaded slide came down at clearly said "I'm the boss" to everyone around. Never has answering a phone been so exhilarating... At least give us a phone with a slide so I can once again feel the pure exhilaration of pressing that slide release button. I need that in my life!
If they're smart, they'll do something like this for the 20th Anniversary release of The Matrix.
Strictly speaking, simply running Android doesn't mean it *has* to be the smartphone we all know and hate.
Japan, for various reasons, caught on relatively late to the smartphone craze and has had a number of flip style phones that you'd swear are BREW, and look pretty close to the late-model LG feature phones (Voyager, etc) circa 2010, but actually use an Android OS -- simply without all the Google stuff actively on top of it.
That's bullshit. Speech recognition was at like 97% or so for years before people had always on connections. And it gets even easier if you're dealing with commands and have people using fixed commands. Sort of like what Google does with OK Google. If you add House Activate or something similar before the command, then the system just has to see if what you said matches a known command.
The only thing that's at all tricky about it is setting it up so that it doesn't activate in response to the TV or radio.
^This. Mod parent up. Natural language parsing and speech recognition has been improving for years, and even Apple has finally allowed "offline recognition" options for their base system.
Going to the cloud makes it *easier*, since it vastly increases the number of samples and allows them to not care about processing resources at all and be generally shit programmers unless their project eats up too much of the internal balance sheet.
We all have computers far more powerful than are necessary to do this in our pockets. Add a desktop system to act as a central unit (not an unreasonable requirement) and to offload any particularly difficult recognition task to and it's entirely possible to have it all work internally.
a lot of media streaming CDN's use DNS resolving to find the closest server to you. if you're on the east coast and use some DNS server 2000 miles away then that's where your content is going to be streamed from. not a local server
^This.
I can't believe how many people don't realize this, put in Google's public DNS because they think they're being cool (and not being tracked), and then complain that an A record comes back that's 18 hops away from them.
I've long held a theory that my ISP (Cox) is limiting bandwidth selectively by site, and that they make all the benchmark sites wide open, but throttle others, like netflix. It seems they have already added fast.com to their "Do not throttle" list but not added Netflix.
So... do you have any evidence for your theory? Or is this just a theory? Outside of emergency/defensive purposes, ISPs only "care" to the extent that there's a financial reason to care and, depending on the site, it makes far more sense to host a local caching server for a high-volume service (eg, Netflix) than throttle it in a way that anyone will notice.
This all depends on ISP size and connectivity, of course, but FWIW I've had Cox for 15 years in San Diego, worked at ISPs here in the city from 2000-2008, and have never noticed any particular limiting that wasn't most likely -- and easily explained by -- technical issues.
In future, the designers imagine a world where people walking past you on the street could find your social network profile by sneaking a photograph of you, and shops, advertisers and the police could pick your face out of crowds and track you down via social networks.
As seen in: Watch_Dogs (2012), Eden of the East (2009), Minority Report (2002), and plenty of other science fiction of one form or another.
Slashdot Mirror
Here is a hint: computer "neural networks" are nothing like how brain neurons work. The fact that people bleat on about "neural networks" just shows that they don't know how AI works. NN are a dead end.
They don't need to be like how brains work at the symbol organizational level, at least not any more. We can get there by just throwing interconnected data at it now. Sure, it would be more efficient to continue building that, but we're at the point where we're just a few Moore's Law updates away from being able to represent it at the synapse level without understanding the higher processing at all.
In some ways, that's even scarier. We'll have AI and not understand how it works any more than how we understand the brain works now.
We are no closer to AI now than we were 70 years ago. All we have now is better dB lookups. *yawn*. Call me when someone creates an approach that has a possibility of creating AI.
We can train neural networks far, far faster than we used to be able to. But outside of that, yeah, nothing except standard evolutionary improvements. Eventually standard improvements will be enough, but we won't notice that happening. 3D printing is starting to move on from plastic and we'll get a nice boost out of that far sooner than any AI improvements coming down the stream.
^ This. Vastly increased networking and data collection makes some of the previous growth requirements predictions meaningless. With enough data coming in (sensory-level), you don't need strong AI algorithms, you just need a neural network that can be bootstrapped.
Alphabet has clearly demonstrated the rapidity at with AI can be developed if you just shove data at it. Who need to sit there training a voice recognition product for years when you can just turn on the microphone in Android and have 100M people in the US providing voice samples all day long? There's petabytes of data out there waiting to be analyzed. Eventually, you don't need to hack your way to AI programmatically, when you can "brute force" your way to it by shoving it the data we're all providing the AI companies with on a daily basis.
And let's be honest; that's what Alphabet is: an AI company. That's the future of information.
Meh, they were talking about neural nets back when I was in school. If it has only progressed from Chess to Go in that time, then it has a long way to go.
That's pretty myopic.
Facebook's AI can predict when people are going to start dating with 96% accuracy, which is better that most human friends will be able to do. Google Now aggregates every bit of data Alphabet has on you and can predict where you're going to go tomorrow evening, when, who you'll be with, and probably what you'll order to eat there. Facebook knows how you're feeling and will display ads to you appropriately. These are generic neural nets, not specialized. And when you shove petabytes of data in, it really doesn't matter. Finding correlations between one set of data is limited only by how much you can throw at it now.
As predicted, the Singularity is Nigh. Furthermore, we're approaching the Singularity faster and faster due to the increased amount of interconnectivity nowadays. Today, you can probably re-ingest the entire useful volume of data in the CyC project just by aggregating Android microphone and location/sensor data at Alphabet.
We don't have a long way to go any more.
Are you sure the change originated with systemd I had heard the opposite.
Fedora/Rawhide was affected as well. The default was changed in 230:
Changelog
The article is wrong. Systemd didn't change anything. Debian's config for systemd changed a default. Either option is a problem for people. But its not unreasonable to assume that users that want to have long running process know more about their systems and thus how to change them than users who want everything to stop when they logout. The change in default makes sense, and systemd is doing the right thing here.
What's a pain is the disruption caused by transitioning from a non-sensible default to a sensible default.
Your comment is wrong.
Debian didn't *intentionally* change the default. Systemd did. Debian failed to catch/care/notice/revert the change. This happened with Fedora as well (well, rawhide, Fedora's rolling unstable branch).
When you add in the systemd project's stated intent to make it more and more painful to NOT use the systemd defaults across the board (cf. https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html), mincing words about distro-level deviations from upstream is not a very compelling response.
And in what way does this new mechanism "enhance security"? Running something in the background after you log out doesn't give you any more privileges than if you remained logged in.
I get people being angry about Systemd, change is hard on people and giving up behaviours/knowledge that the community has prided as a point of recognition feels like losing a culture divergence from the Unix philosophy. Unfortunately they're looking at it from the wrong perspective.
The proper perspective is to understand that Systemd is a significant conceptual step towards targeting the enterprise with Linux. This change has made it so Linux effectively now has a centrally manageable remote process control system built in by default. This is an additional level of control over user space processes, which at the enterprise level, is a very valuable feature. Effectively the *nix version of Microsofts "Applocker" in an environment where a user often operates at higher levels of permissions. That's how enterprises operate their networks and a significant step up in securing Linux from that point of view.
Don't dare say sudo in response, great single system low user count idea, but again I'm talking about the enterprise level, hundreds of thousands of servers, desktops and accounts.
This might make sense if Enterprises were adopting EL7 en masse. They're not. All the fancy newfangled features are meaningless if the system is no longer trustable or reliable, or can't reliably (and deterministically!) boot. And the vast majority of the complexity isn't around resource management, it's dealing with events occurring because Lennart moved his laptop from one coffee shop to another. Enterprises *that* focused on security that some of the new features might be worth it for have already found solutions on EL6 for the most part.
Individually, there are some neat features. Collectively, systemd is a complete and total disaster being guided by a loon with delusions of grandeur who doesn't give a F about anything besides his use case. Enterprise people have seen that kind of thing before and know how unreliable those projects end up being.
You're correct in that it can cause race conditions, but you're not giving sufficient weight to the fact that admins have heterogenous solutions for those. Who watches the watcher? Maybe a cron job. Maybe puppet. Maybe another service. Maybe monit or any other monitoring system you have. An administrator should look at their own likely failure states and automate accordingly.
How many times has xinetd crashed on you in the last 10 years? How often does daemontools or supervise crash on you? These types of servers are single-purpose designed and have well tested code. Small, simple, focused programs that do one thing and one thing well precisely to reduce the problems that can result. /sbin/init forking a shell and forking a small bit of C code (eg, svscan) with a monitor running via cron (and maybe a second monitor running persistently as a distinct service) is oodles more auditable, reliable, and understandable than a monoculture of systemd attempting to be responsible for everything.
Note quite. Fedora is not the upstream for systemd, systemd is its own upstream and frankly has been driven more by CoreOS needs than Fedora ones recently (with the whole resolved and networkd stuff which are not used in Fedora since we use NetworkManager). Check the number of patches in the F24 spec for instance. The discussion is ongoing at the moment and this will become a F25 change that gets debated by FESCO. It's likely that the Server and Workstation product, for instance, may split in their behaviours here given the different use cases.
Be fair. That entirely was the situation. It's a neat sophist trick, wearing the upstream hat and the downstream hat and claiming the other guy with the hat is tying your hands. (Not you personally, the collective "you".) https://bugzilla.redhat.com/show_bug.cgi?id=1170765#c58 The simple fact is that huge bits of what once had been Fedora-level policy is now more or less handled by "upstream" and there's continual pressure to not deviate from upstream. Anyone with any experience in any sort of team politics should be familiar with that.
No it is an attempt to fix our broken init landscape (it's notable that no one wanted to keep sysvinit as the default in the Debian CTTE decision) and solved not only the sysvinit problems but the upstart ones as well.
Fedora is a well integrated distribution with
Again and again I've heard people like you suggest that Slackware is a replacement for a modern mainstream distro like Debian. Others suggest Gentoo.
Well, the reality is that neither is sufficient.
Slackware is, to put it politely, very primitive. While simplicity is a good thing, Slackware takes it to the point where it becomes a liability.
When using Debian, it's possible to get a full-featured desktop or server set up with very little effort, and this can be done quickly. Thanks to sensible defaults and a practical installer, manual configuration is kept to a minimum.
Frankly, what we need even more than Devuan is a fork and re-structuring of the RedHat ecosystem. Unlike .deb-land where the more dynamic Ubuntu is a downstream of the stabler Debian, the "upstream" of RPM world is the bleeding edge Fedora where this crap began with, not the more-enterprise-stable RHEL.
The unfortunately-named CentOS ("Community ENTerprise OS") is an intended binary-compatible rebuild of RHEL, so it really doesn't have the freedom to change anything at all and remain within its goals (even before it became part of RedHat). What's needed is a sane, more stable fork of Fedora.
It could be done... Start with CentOS 6 as a baseline, and bring this up to date with CentOS/RHEL7 tech (kernel, glibc etc.) using Scientific Linux 7 as a concept for rebuilding. Bring in stability features, while leaving out as a requirement what's generally a poor fit for a server, such as systemd as /sbin/init, NetworkManager, etc. It doesn't mean they're not there, but they're not forced. systemd can still run, it just isn't PID1... It's a service launched via script just like any other service manager (such as xinetd).
From there, build a server-quality distro that's broadly (generationally) compatible with the major release of RHEL, but is free to not do the stupid stuff.
RPM-world needs and deserves a new, server-class RPM-based distribution.
I am yet to see a use case presented that the existing initd system cannot handle if you take the time to understand how to use it properly.
Really? Because I can't remember the last time I ran a Linux system where init didn't launch some other daemon with the express purpose of handling all the stuff it wasn't able to regardless of how well you understood it.
Woosh.
THAT'S EXACTLY THE POINT. Need something /sbin/init didn't already do? Have it launch another, specialized service manager of your choosing. Have it launch several! Original inetd, xinetd, crond, supervise/daemontools, linux-ha / heartbeat, ... plenty of options. Have it integrate with other systems however you need it to. That's why you're an administrator.
The point is: none of those other daemons pre-supposed that they were the only ones, pushed out other ways of launching services, or needed to exist as PID 1 (of which there can obviously be only one on a given running system). /sbin/init was kept simple and agnostic.
As now I am being told that I'll have to make modifications to the way somethings that have worked for years.
For that you can blame the maintainers of your distribution. After all they are the ones who rolled out an update to you with a default blindly set from upstream despite it not being compatible with the way the rest of their system runs.
There's blame to go around. The specific, stated goal of the systemd developers is to make it harder and harder to use configurations and setting that they do not approve of. Through a series of what they call "gentle pushes", they want to unify Linux userland across the distros. The history of the last 5 years is that the default will soon become mandatory.
But yes, fail on the Debain devs for not standing up for the distribution. (Fedora can't even do that any more... Fedora IS the upstream and there's basically no one who can push back at the Fedora level for a dumb upstream systemd decision. Debian... don't be Fedora.)
If you want systemd so badly - why don't you just make it a service of initd?
The irony of recommending the exact thing that systemd was made to avoid is unfortunately lost on the fact that this fundamentally doesn't work if any of systemd's functionality is to work at all.
Why are you guys, who cannot demonstrate you know any better, subjecting everyone to use this?
Who guys? The guys who invented cgroups? The guys who wrote kernel support for it? The guys who have put effort into replacing init over the years? The guys who compile a distribution with software of their choice to "best suit their users"? The guys who don't chose sane configuration options?
Who is subjecting you to use something against your will?
systemd was and is a power grab, plain and simple. Grab as much land as you can, make it "too convenient" to not give in to additional power requests on the grounds that it makes your own life easier, and suddenly the frog is quite boiled and you're trapped. Go back and look at any of the small decisions over time from Fedora 15 onward made to make it extremely inconvenient to use any other init system anywhere in the ecosystem. From hard dependencies to banning the inclusion of any sysvinit scripts (even as an option!) in RPMs in Fedora, which serves as the de-facto upstream for basically all RPM-based distributions. People who didn't want to use systemd absolutely were being subjected to it against our will. To claim otherwise is ludicrous.
The vast majority of systemd AS IT WAS ORIGINALLY PROPOSED does not need to function as PID1, because it forks other things from it. The only thing special about PID1 is that that's where parentless processes go. A systemd binary can launch other processes beneath it and remain in complete control over them for the vast majority o
They do not dogfood Linux on their desktops.
They log in remotely via SSH running on macbooks...
No, it's actually the opposite, which is quite a bit worse.
They only dogfood their shit on their [macbooks]... And the occasional virtualized cloud container bollocks. In short, they're thinking ONLY in terms of a Developer, and a specific type of systems administration that basically consists of hard-coding their administrative decisions into code. Well, bully for them. Congrats on making their own specific, unique use cases work better for them. Unfortunately, they're so full of themselves they don't think any other use cases matter. If you're not doing it this way, You're Wrong... no matter what you've been doing previously.
Did you install systemd from source? No, you install it from your distribution. Are they going to install with the feature on or off? Why are you suddenly spurned by the default behaviour of something trivially overwritten becoming the default? If its a dumb change, all distro providers will ship it off by default and nothing of value was lost.
Their stated goal is to subsume the the distro's decision-making process by continnually nudging them to their preferred defaults. "Harder and harder to use things the wrong way", IIRC.
So tell me, just how do you keep track of a started service, to verify that it is indeed running and to shut it down cleanly? If you have any better solution than pidfiles, I'd love to hear it.
And yes, that is one of the things that systemd solves. I may not always agree with the default settings chosen, but systemd exists because there are good technical reasons for something like systemd to exist, and the systemd devs are apparently the only ones who don't stop at whining but actually code. So long as the haters do nothing but whine, you will have to put up with Pottering's insights and foibles.
Wrong. pid files and subsys locking worked and continue to work fine for the vast majority of cases. CentOS 6 / RHEL 6 is still super-widely deployed and many enterprise shops are delaying moving to EL7 (when they otherwise might be right around now) specifically because of systemd and a few other changes. Somehow, we're managing to run a modern system without using systemd... Crazy, I know!
For those that *do* need a service manager, there have already been solutions written for it. I use daemontools personally, but other people have different tools. The point is: Almost nothing that systemd does with regards to service launching couldn't be (and isn't already) done with some combination of "normal init scripts", xinetd, and daemontools. It's one true nifty feature in that area is automatic cgroups management, but frankly that feature alone is nowhere near worth the hassle of dealing with all of the other crap they're doing.
But was this the systemd developers at fault or the person who build the installation package? .deb.
It sounds more like a lack of configuration with a
The systemd developers' stated goal is to "provide gentle nudges" continually to synchronize any downstream users (in this case, meaning distros and users) to their view of what the proper use is; and this has been matched over the years by their actions.
Furthermore, on the Fedora side the Fedora devs have basically abdicated formerly-distro-level decisions like that to "well, upstream has made this change and we want to stay in sync with upstream."
FWIW, I've only found one quote by Lennart Poettering about the entire thing (source):
I am not sure I follow. Note that user@.service is already reference counted by the login sessions around. i.e. it is started before the first user session of a specific user is created, and stopped when the last user session ends. I don't follow why that behaviour is not sufficient?
Lennart seems to have learned by now to be careful what he says in public, so I don't expect him to call anyone a moron here.
No, there's a similar debate blowing up on the Fedora list as well, it's just that there's hardly anyone left with the energy to fight the cabal any more.
From the Fedora List:
Re: Serial Experiments Lain did it first!
The unshaven guy looking for the Knights of the Eastern Calculus IIRC. Unfortunately for him, he got more than he signed up for.
I came here to post exactly this. Mod parent up :D
https://www.youtube.com/watch?v=H1oAczD98pk&feature=youtu.be&t=4m23s
You realize that the AMP pages are essentially static, right? The required styles (if you read Google's AMP tutorial) supply some webkit animation bullshit, but there's nothing really "interactive" about the AMP webpages that you see atop Google News now. In fact, what you're getting isn't actually much different from what you'd find in RSS (just via some extra json crud instead of straight XML like the content basically already is). Everything else in AMP (like amp-ad) is just reinventing the wheel badly.
If I read you right, Google Reader has returned from the dead in the form of the worst XSLT you've ever seen... and more spying.
If "using more closed source software" means the freedesktop.org guys and/or their target audience moves over to shiny new Mac Books and leaves the Linux ecosystem alone, I'm all for it.
Not just systemd, but a lot of the other work that has come out of the Linux-on-the-Desktop-is-right-around-the-corner community has destabilized lots of working server installations. Maybe once they can be convinced that the future of the App crowd is back in the closed source hosted or closed source ecosystem area (hint: it is), we can start to wrest control back and begin picking up the pieces.
The RAZR was good, but for me the most iconic phone has been the Nokia 7110. The thrill of pressing the slide release button was simply unrivalled. The almost dangerous speed that the spring loaded slide came down at clearly said "I'm the boss" to everyone around. Never has answering a phone been so exhilarating... At least give us a phone with a slide so I can once again feel the pure exhilaration of pressing that slide release button. I need that in my life!
If they're smart, they'll do something like this for the 20th Anniversary release of The Matrix.
Holy sh*t, we're old.
Strictly speaking, simply running Android doesn't mean it *has* to be the smartphone we all know and hate.
Japan, for various reasons, caught on relatively late to the smartphone craze and has had a number of flip style phones that you'd swear are BREW, and look pretty close to the late-model LG feature phones (Voyager, etc) circa 2010, but actually use an Android OS -- simply without all the Google stuff actively on top of it.
One example: http://www.kyoex.com/sharp-504sh-aquos-keitai-android-5-1-flip-phone-unlocked/
How about a device the monitors your pictures to make sure they are hanging level and sends status updates to your phone?
You should Kickstarter that.
That's bullshit. Speech recognition was at like 97% or so for years before people had always on connections. And it gets even easier if you're dealing with commands and have people using fixed commands. Sort of like what Google does with OK Google. If you add House Activate or something similar before the command, then the system just has to see if what you said matches a known command.
The only thing that's at all tricky about it is setting it up so that it doesn't activate in response to the TV or radio.
^This. Mod parent up. Natural language parsing and speech recognition has been improving for years, and even Apple has finally allowed "offline recognition" options for their base system.
Going to the cloud makes it *easier*, since it vastly increases the number of samples and allows them to not care about processing resources at all and be generally shit programmers unless their project eats up too much of the internal balance sheet.
We all have computers far more powerful than are necessary to do this in our pockets. Add a desktop system to act as a central unit (not an unreasonable requirement) and to offload any particularly difficult recognition task to and it's entirely possible to have it all work internally.
That said, I have Cox on the 100 MB/sec down plan...
I kind of doubt you're on the 100 MegaByte plan. It's doubtful Cox could even deliver those speeds.
He probably means Mbps, but FWIW Cox does have a 1Gb plan in some markets.
a lot of media streaming CDN's use DNS resolving to find the closest server to you. if you're on the east coast and use some DNS server 2000 miles away then that's where your content is going to be streamed from. not a local server
^This.
I can't believe how many people don't realize this, put in Google's public DNS because they think they're being cool (and not being tracked), and then complain that an A record comes back that's 18 hops away from them.
I've long held a theory that my ISP (Cox) is limiting bandwidth selectively by site, and that they make all the benchmark sites wide open, but throttle others, like netflix.
It seems they have already added fast.com to their "Do not throttle" list but not added Netflix.
So... do you have any evidence for your theory? Or is this just a theory? Outside of emergency/defensive purposes, ISPs only "care" to the extent that there's a financial reason to care and, depending on the site, it makes far more sense to host a local caching server for a high-volume service (eg, Netflix) than throttle it in a way that anyone will notice.
This all depends on ISP size and connectivity, of course, but FWIW I've had Cox for 15 years in San Diego, worked at ISPs here in the city from 2000-2008, and have never noticed any particular limiting that wasn't most likely -- and easily explained by -- technical issues.
In future, the designers imagine a world where people walking past you on the street could find your social network profile by sneaking a photograph of you, and shops, advertisers and the police could pick your face out of crowds and track you down via social networks.
As seen in: Watch_Dogs (2012), Eden of the East (2009), Minority Report (2002), and plenty of other science fiction of one form or another.