Shuttleworth Says Snappy Won't Replace .deb Linux Package Files In Ubuntu 15.10
232
darthcamaro writes: Mark Shuttleworth, BDFL of Ubuntu is clearing the air about how Ubuntu will make use of .deb packages even in an era where it is moving to its own Snappy ('snaps') format of rapid updates. Fundamentally it's a chicken and egg issue. From the serverwatch article: "'We build Snappy out of the built deb, so we can't build Snappy unless we first build the deb,' Shuttleworth said. Going forward, Shuttleworth said that Ubuntu users will still get access to an archive of .deb packages. That said, for users of a Snappy Ubuntu-based system, the apt-get command no longer applies. However, Shuttleworth explained that on a Snappy-based system there will be a container that contains all the deb packages. 'The nice thing about Snappy is that it's completely worry-free updates,' Shuttleworth said."
why bother? (Score:5, Funny)
The functionality will be built in to the next version of systemd.
Re:why bother? (Score:5, Informative)
why is this modded troll?
Lennart the great mastermind has announced it on his blog: http://0pointer.net/blog/revis... [0pointer.net]
systemd will be a distribution (Score:2)
sooner or later.
now why would someone let guys who want to do that make their bootup system? it will have it's own kernel soon enough too and it's going to be forking time again for all the distros
Re: (Score:3, Insightful)
Wow. Now i really am starting to get why people hate this guy.
Re:why bother? (Score:4, Interesting)
Maybe you should actually read what he wrote before jumping on the hate bandwagon. He's absolutely right that for many years and applications traditional package systems fall down. That's not to say they aren't important. They are and will continue to be. But they have their limitations when it comes to fast moving software like libre office on a nice stable slow moving distro like the lts releases of Linux distros.
As a matter of fact docker is really one attempt to solve this problem. Coreos is based on this idea. Chromeos also eschews packages entirely. Now snappy.
And as experimental distros like snappy try things, new utilities will have to be created to manage the images. This is what Poettering is talking about. In the meantime you're free to not use any of this. It's just a bunch of ideas, many of which happen to be really good, and natural extensions of the traditional package model. It's exciting stuff.
Re: (Score:2)
Sigh. That should have read, for many types of applications. Not many years. Google's swiping keyboard is pretty good but always makes a few mistakes.
Re:why bother? (Score:5, Insightful)
No they don't fall down. I've heard this claim and it's frankly not true (or rather, true in a very very limited set of cases).
For first party packages (distro provided) it's business as usual: ubuntu seems to have no trouble tracking the latest firefox builds and there's a fresh deb available via apt-get update && apt-get upgrade in a very timely manner. Likewise there's the fresh and still LO packegs available depending on whether you want stability with timely security updates or bleeding edge.
So, demonstrable, fast moving packages are not a problem.
What about third party ones?
Basically it's the same. Add a PPA for the third party repo and it just works. Now, if the third partd dev doesn't want to keep up to date with system libraries which may change, then they might choose to ship their own .so files. That has the downside of not tracking security updates, but since linux package managers are the only system where arbitrary packages tend to get security updates to arbitrary libraries anyway all that does is lower the performance to that of every other OS on the planet.
And some programs do this: they provide a third party .deb or PPA and dump files in /opt/foo completely isolated from the system files in/usr. That works very well too.
One of the ways that packaging falls down traditionally is for multiple versions of the same package installed concurrently. Part of this is because some programs themselves are not build for that (e.g. expecting files in /etc), however most package can be persuaded otherwise and there are in fact package managers that solve this problem.
The other way is if a program needs a complex system relying on multiple non-default configured packages to be set up. At that point, it's often easier to ship an entire system image.
However, doing system images for everything seems a tad wasteful.
The other thing that is hapening is Zawinski's cascade of attention defecit teenagers. Yeah, I know packaging isn't perfect in general and deb is not perfect in a number of specific ways. But the people who want to dump everything and start afresh often seem to be quite unaware of teh state of the art. The results is that the new systems are usually better in some ways, but inevitably worse in a number of ways that the author didn't think of but have been hammered out and working well for 20 years in other systems.
It's sad because to someone who's around for a long time, software doesn't so much as advance as take an awful lot of steps sideways. You get big fat brand new shiny systems which just plain do a bad job of previously solved problems.
This seems to be the same: many of the reasons for doing away with packages are flat-out wrong which strongly implies that the people replacing packages don't really understand packages properly and are therefore likely to make a bunch of new mistakes which have previously been solved perfectly fine. So even if they solve some problems (I have no doubt they will), they'll also unsolve a bunch.
Re: (Score:2)
Zawinski's cascade of attention defecit teenagers.
What a great description.
Re: (Score:2)
It's exciting stuff.
Is there really a part in there you consider exciting?
Re: (Score:2)
It's their yummy new almond flavoured product.
Re: Kool-Aid (Score:2)
I actually what you're smelling are lolmonds, a newer relative of almonds.
Re: (Score:3, Funny)
Yes, how dare he develop software that people can use if they want to, the bastard.
Re: why bother? (Score:2)
Youre assuming that "convenient for distro developers" translates into "valuable for users".
More over you are ignoring that having it adopted as a dependency by things like gnome largely tied most distros hands. Dedicated non-gnome distros are the only ones that made a choice. Any distro that wants to ship gnome (an utterly unrelated product) did not choose systemd as there was no choice available.
Re: (Score:2)
Either quite a few people love him or many distros adopted systemd on a technical basis. Which option worries you more? :)
Re: (Score:3, Insightful)
Re: why bother? (Score:3, Funny)
Pid eins is an anagram of iPenisd - now I understand...
Re: why bother? (Score:2)
Please use Type=forking in your unit file to get the behaviour you are expecting. It's covered in the man page.
Re: (Score:3)
That's because the systemd manpage is about the main application. You want the systemd.service manpage.
Re: (Score:3)
You systemd haters are really hilarious.
Where else do you get to see somebody professing their love of the True Unix with Unix Philosophy, while repeatedly demonstrating ignorance of the very system they claim to love so much?
Allow me to impart a bit of education: some things have more than one manpage. For instance there's a manpage for both cron, and crontab, and Perl has a whole bunch of them. Any competent admin would know this and wouldn't be mystified by systemd having separate manpages for commandlin
Re: (Score:2)
Hah, I knew it. You have no ability to hold a technical discussion.
If there's somebody not needed here, it's people who are ignorant and proud of it. If you actually want to contribute something useful, start coding. You discredit your own cause by posting this nonsense.
Re: (Score:2)
So, what you're saying is: you must first elaborately troubleshoot system just to just freaking stderr so you can troubleshoot what you actually care about? Truly a step forward!
Re: (Score:3)
Actually it is a step forward.
In sysv land, this is the difference between letting a service fork by itself and using start-stop-daemon. If you take the later approach, start-stop-daemon will perform the daemonization task on behalf of the service. In such a case if it ever prints on stderr, it will be lost in the void, since it's no longer connected to any terminal. systemd actually will ensure it goes into the log.
Re: why bother? (Score:5, Informative)
What are you on about?
There's your stdout and stderr.
Re: (Score:2)
He doesn't know how to use journalctl and doesn't want to learn. He just wants to grep syslog the same way he has done for 30 years.
Re: (Score:3)
If something has worked fine for 30 years, why the fuck would you change it? Windows is the OS that pointlessly moves around all the administrative tools with every release; Linux is the OS that doesn't. That's not to say the OS can't change, but the new pieces must be backwards compatible with the basic system debugging techniques everyone knows. All it takes is software developers who don't actively hate their userbase and find joy in punishing them.
Re: why bother? (Score:4, Informative)
Actually no, it hasn't. sysv init has long been a pile of hacks on top of a pile of hacks. Ever tried to write a sysv service? It's really wonderful when a service refuses to come up because the pid file was left around for whatever reason, and some other program happens to be running under that pid.
For instance, the stderr thing this guy is complaining about was long a "feature" of sysv systems, where stderr could actually disappear into the void. Systemd actually makes things much better by ensuring stderr always gets saved.
As to why change logging, under systemd you can trivially ask for the messages for a particular service, or the messages from last boot, without having to figure out what to grep for, or having to setup syslogd beforehand to sort out your messages into separate files.
Re: (Score:2)
Systemd actually makes things much better by ensuring stderr always gets saved.
Your naive faith is cute. Sure, sysvinit is not wonderful. Regardless of the status of other init systems, SystemD is NOT the right answer. It is unreliable. It is taking over everything, which makes it a huge brittle obstacle that can be abused by those who control its underlying behavior. The guy writing it already has a terrible reputation for quality: Pulse Audio.
I could go on and on, but why. Some people are evangelists and there is no talking sense to them about the dangers of what is being proposed.
Re: (Score:2)
If something has worked fine for 30 years, why the fuck would you change it?
Good question. If something has worked fine for 30 years then no one would want to change it right? Certainly no one would be demanding the features? No one really wants easy commandline based syntax to extract exactly specific logs they are after.
Now back in the real world go ahead and install syslog-ng and dump all your crap into a text file like you're used to, and leave those of us who think that being a fucking regex guru should not be a pre-req to reading a log file alone.
Let me guess, you didn't even
Re: (Score:2)
That's not to say the OS can't change, but the new pieces must be backwards compatible
Sure. But the limitation here is not with systemd, but the fact that systemd has to communicate with syslog through a socket, and the socket has a limited buffer for storing queued messages. So if you need critical, timing-dependent log messages, you really need to use journalctl. If you refuse to use journalctl then you are shooting yourself in the foot and complaining that it hurts.
Re: (Score:2)
That's a stupid attitude to have in a field that moves as fast as computing. The internet didn't exist in anything resembling the current shape 30 years ago, just to give an example. You don't get to excuse ignorance of networking just because of that. I don't see how it's viable remaining a sysadmin without dealing with the fact that the hardware, software, and needs of the organization are constantly changing.
Nevertheless, all it takes is "ForwardToSyslog=yes" in journald.conf.
Re: (Score:2)
Well, if you understood anything about the project, you would know that rebuilding the init system and rebuilding the log system are two separate projects. There are independent rationales for each of them. You are free to disagree, of course, but they exist. And a counterargument of "it works for me" is less than useless in a discussion about whether the change is necessary. Given that there are a lot of people who do think a change is necessary, you should make a better attempt to understand why and make
Re: (Score:2)
You are all completely fucked, and clearly show your lack of maturity and competence.
What an odd statement.
Look AC, learn something about the way the linux kernel works, and then maybe you will be able to understand the problem. There can only be one logging daemon attached to /dev/log. If it is journald it is journald, if it is syslog it is syslog. If you want both, one has to forward information to the other, and the amount and speed by which that forwarding can take place (via sockets) is limited by the kernel. So syslog missing messages that journald forwards, is an inherent limitation
Re: (Score:2)
Those desiring the change are the ones that need to explain why the change is needed/desirable in the first place.
They have, many times and in different places. If you didn't know that, maybe you should do some research.
I said that the arguments typically presented were weak and unreasonable.
So you do know that arguments and rationale have been made. Ok, how about a substantive counterargument then. Preferably one that actually addresses the arguments given and doesn't just dismiss them as "weak and unreasonable."
The ridiculously common command line that you wrote above fails on many/most distros that have chosen systemd as a default. These systems have no syslog at all.
Every distro that I know of (Red Hat, CentOS, Debian, Ubuntu, Arch) currently installs syslog alongside journald. If you don't have syslog installed, install it, and take it up wit
What happens with Launchpad PPAs? (Score:1, Interesting)
How? (Score:5, Insightful)
I don't think it was the PACKAGE that caused people to worry about an update.
Isn't that an issue with the code itself?
The great thing about .deb packages was that the OFFICIAL ones underwent a lot of testing to try to catch problems BEFORE they were deployed. NOT because they were magical .deb packages.
Re: (Score:3)
Exactly - it is almost if they were trying to give a bad name to OS software.
There are very good reasons that Debs act like they do - and even M$ is now adopting the repository approach (but of course if the code isn't open, it can't prevent bad things from happening).
One could make the argument that all software should be it's own blob - no dependencies because hardrive are now huge - but having 6 different versions running reduces the chance that someone else will be facing the same bug as you are - and m
Re:How? (Score:5, Insightful)
I've seen software that depends on bugs to function
Back in the 90s, I had to intentionally reproduce Microsoft bugs in my Windows drivers, or various apps that had never been run with non-Microsoft drivers would fall over...
But, yeah, let's make Linux do things the Windows way, so you have sixteen copies of different versions of zlib.dll spread across your disk, all with different security holes. Because you know it makes sense!
Re:How? (Score:5, Interesting)
The great thing about .deb packages was that the OFFICIAL ones underwent a lot of testing to try to catch problems BEFORE they were deployed. NOT because they were magical .deb packages.
I think they are still standing on Debian's shoulders here, and their Snap files are being automatically created from based on the .debs. The main feature of a Snap file is it combines all the libraries in a single archive. All the dependencies, everything. It installs them locally, not for the whole system, kind of like an .app file on OSX.
If that seems like it would take a lot of disk space, Ubuntu is hoping disk deduplication will take care of that.
Re:How? (Score:4, Interesting)
All the dependencies, everything. It installs them locally, not for the whole system, kind of like an .app file on OSX.
So.. they install things in Linux containers (or namespaces) and then call it "snappy"? So why not just link everything statically?
Anyway, I don't get it. You can do that already. but you still need to get those apps to communicate with outside world, which means leaky containers at best.
Furthermore, in case of heartbleed, it would mean EVERY single application that uses OpenSSL would have to get rebuilt instead of just getting fixed library and rebooting.
Re:How? (Score:4, Interesting)
I think there is definitely room in the Linux world for a self-contained App container. I don't think it's a good idea to make every package in your package management system self-contained, though.
Re: (Score:2)
Wheres the hate like systemD? (Score:2)
This also doesn't follow the Unix philosophy. Replaces a tool everyone is familiar with too. But I see no foaming at the mouths this time.
Re: (Score:3)
This also doesn't follow the Unix philosophy.
What part of the Unix philosophy doesn't it follow?
Replaces a tool everyone is familiar with too
It is a package manager, competing with plenty of other package managers out there. If you use this instead of Yum, it's not going to affect which GUI you use.
Re:Wheres the hate like systemD? (Score:5, Interesting)
As others have already pointer out, you are wrong for assuming this is like systemd, so I won't further beat that horse.
However I think it's foolish for Shuttleworth to go down this path. It's inevitable that systemd will start to require that it get's it's hooks into package management. Long story short, the way fixes are applies to systems is fundamentally broken. Whether it's because someone can't find a way to tell what needs to be restarted or can't impose a way to restart all services without down time or can't find a way to apply changes to all containers or whatever half thought out problem is the excuse, it's broken. And the only fix will be to bundle it into the logic of systemd. Amongst other things, a package format will need to be mandated because supporting multiple formats is stupid or hard or out-of-scope ... you name it.
No one has been able to oppse the systemd maintainers except the kernel developers when it comes users space interfaces. Canonical hasn't been able to stand its ground against these developers in the past. I doubt they will in the future either. Shuttleworth is creating another failure.
Re: (Score:2)
ROFLMAO. http://0pointer.net/blog/revis... [0pointer.net]
I am dying inside. LOL Read your words then read that link then read your words again. You just can't make this shit up.
Re: (Score:2)
pray tell what is the standard package manager for "the unix way"?
There never was one
hence, no problem
Re: (Score:2)
pray tell what is the standard package manager for "the unix way"?
It's called 'make'.
Re: (Score:2)
what is the standard package manager for "the unix way"?
tar
Re: (Score:2)
nah, there is also cpio, ar and shar
Scary Words (Score:3)
"completely worry-free updates"
Those are very scary words when ever someone utters them because they seem to fail to comprehend the fact that testing is not perfect. I have real work to do. When they F*sk my system with an update that fails and it loses my data or prevents me from working, just once, it can be a huge disaster for me. Multiply that times all the users. Not an issue for the developer. Completely worry-free updates. Not.
Comment removed (Score:4, Informative)
Re: (Score:2)
That's the theory. But when they say "Worry Free" it worries me.
Re: (Score:2)
Famous Last Words (Score:5, Interesting)
"The nice thing about Snappy is that it's completely worry-free updates"
Any time anyone says something is "completely worry-free", that's your cue to worry. Ask me how I know.
Re:Famous Last Words (Score:5, Funny)
Ask me how I know.
How do you know?
Re: (Score:2)
Because he's old.
Stop being so Dice-friendly PC! It's because he's a guy.
Re: (Score:2)
Because he's old.
Stop being so Dice-friendly PC! It's because he's a guy.
No, no...it's because I'm a guy AND because I'm old. Sheesh.
It will be gone in a few releases (Score:2)
Like upstart.
we're only thrilled to hear, what poettering will introduce. Because redhat will adapt it and then everyone starts using it, because if its poetteringware, it's quasi standard, isn't it?
The Linux community is destroying itself. (Score:5, Insightful)
As a long time Linux user, I'm dumbfounded by how the Linux community has basically turned on itself over the past 5 years.
It's not Microsoft, nor SCO, nor Apple, nor any other external entity that's destroying the usefulness and practicality of Linux. It's the Linux community, as a whole, that's doing this!
Systemd is the obvious example of this. Never have we seen a piece of software so divide and devastate the Linux ecosystem. Whatever small amount of convenience it may bring for the maintainers of Linux distros is more than offset by the many problems that systemd has caused the users of these distros. It doesn't matter if, say, the Debian maintainers' jobs are made easier if Debian itself suffers from reliability problems thanks to systemd that drive the most important Debian users over to FreeBSD.
But that's not the only example. We've seen the usability of Linux on desktops and workstations devastated by awful desktop environments like GNOME 3 and Unity. This mad rush to target "normal" users has been an utter disaster. No normal users have actually decided to use Linux due to these changes, but many long time Linux users have been forced to find alternatives.
If we go back 10 years, to 2005, I never would have expected Linux to be in such dire straits, and all due to problems that the Linux community has imposed on itself. It's really unbelievable how much harm the community has done to itself as of late.
Re:The Linux community is destroying itself. (Score:5, Interesting)
I'm not sure it's "the community" that's to blame as much as certain large entities in the community (*cough* Red Hat *cough*).
First, about systemd. Exactly what "problems" has it caused the users? On a normal distro, it runs in the background and should be transparent. sysvinit was ancient, and not even Solaris (the last true UNIX) uses it, it switched to SMF ages ago. All the anti-systemd hysteria I've seen has only been about vague possibilities, or whining about "the one true UNIX philosophy" (which again, apparently real UNIX doesn't even follow), etc. Whereas the systemd supporters can actually point to real, tangible benefits. Now admittedly, at home I'm a longtime user of Linux Mint which still runs on upstart for the moment, but I've been using CentOS 7 machines at work and I haven't run into any problems there (except for fucking Gnome3, more on that later). systemd seems to me to work just fine.
However, with Gnome3 and Unity, you're exactly right. The two most powerful and influential distros (Fedora/RHEL and Ubuntu) both changed to awful DEs, which certainly can't be attractive to new users who aren't looking for something that's a complete sea-change from the UIs they're used to. By all rights, KDE should be the default DE: it's reasonably fast, it's pretty bug-free at this point (compared to Gnome3, which is full of bugs in my personal experience with CentOS7), it's full-featured, it's highly configurable to do whatever you want, whether you want it to be more like Windows or like MacOS, and it's a familiar paradigm. Yes, the "semantic desktop" stuff is useless, but it's actually turned off by default on many distros now I believe, and if not, it's easy to disable and simply ignore--I do. So why Linux distros are pushing minimalistic DEs, I dunno. But I'm certainly not the only one who doesn't like them: there's a reason Mint has become so popular, and so many people have switched to Cinnamon and MATE.
Honestly, the big misstep that started most of this crap was the founding of GNOME back in the late 90s, due to the licensing issue with Qt. They should have abandoned Gnome when Qt finally was released under the GPL, then we wouldn't have these issues now.
Re: (Score:2)
Let me re-write that:
"KDE should be the default DE for everyone because I like it more"
and
"Software should have never been created, because having more choice in FOSS software is somehow bad for the Linux ecosystem."
Can you find the logic?
Re: (Score:3, Interesting)
"KDE should be the default DE for everyone because I like it more"
No, it should be the default because it's highly configurable. Any distro can easily make a preferred configuration instead of making an all-new DE. Obviously, a lot of people hated Gnome3, which is exactly why both MATE and Cinnamon were created. I think it would have been easier if they had put that effort into re-skinning KDE.
"Software should have never been created, because having more choice in FOSS software is somehow bad for the Lin
Re: (Score:2)
no good reason, as KDE has good defaults.
Re: (Score:2)
That's why you're an idiot: the defaults are fine, and there's nothing forcing you to configure it differently.
Re: (Score:2)
How will the defaults being what you want stop people playing with them?
The defaults aren't what I want; they're whatever the distro decides on (which are likely not very different from what the KDE publishes).
There's nothing stopping people from playing with them. How is that a bad thing? Holy shit, is everyone on Slashdot a Mac fan now? That probably isn't even fair to say, since even Macs have some configurability.
Re: (Score:2)
This is stupid.
First, KDE is not really competing against low-resource desktops like LXDE and XFCE.
Second, configurability is not a detriment. If you don't want to change the configuration, then DON'T. Leave it at the defaults. No one is forcing you to go through every configuration option.
My car has a bunch of configuration options in the infotainment system. I can change all kinds of things: audio settings, HUD settings, navigation settings, etc. This doesn't make it hard to drive, because most peopl
Re: (Score:3)
systemd has already broken the kernel repeatedly, a decade of log collection and analysis tools that I personally use, decades of cross-platform tools, decades of network configuration tools, and now it's trying to replace "su" and "/etc" to create a "stateless Linux". I'm afraid that it's a system management tar baby, adhering to every system component that it touches and leaving them snarled in sticky debris that is difficult to wash off.
It has also made ancient aliens take over the congress, caused otherwise normal peoplr to massacre entire cities, and cancer in everyone. finally, tiny little boils that explode annd throw white hot magma on everyone in cows. systemd is the real cause of all those millions of acres of wildfires in Washington state.
Now tell me. It is apparent that you hate systemd with a white hot passion.
so why are you using it? You do not haev to use it, and if you aren't. what on earth are you bitching bout. I mean r
Re:The Linux community is destroying itself. (Score:4, Insightful)
An appeal to ridicule is a logical fallacy: if it were an entertaining appeal to ridicule, it might be amusing, and I wouldn't expect pure logic on Slashdot. But please note that it doesn't address or even acknowledge a single one of the issues I mentioned. Many of those issues are architectural and core to systemd development.
And no, I don't "hate systemd with a white hot passion". It does a few things reasonably well, and there are some real benefits to getting faster boot times and kernel logging. The network integration is problematic, but shows some promise.
But systemd really needs to _stop_ trying to replace core system functions with yet another add-on module. And yes, it's trying to take on software packaging, as well.
Re: (Score:2)
An appeal to ridicule is a logical fallacy:
You assume I'm arguing with you. Use a distro with system d or do not.
However, just as annoyed as you get with my little bit of ridicule, imagine how annoying it is to not hear the word "Linux" without someone bitching about systemd.
If it is the unmitigated disaster some folks say it is, the problem will fix itself in short order.
Re: (Score:2)
And yes, it's trying to take on software packaging, as well.
FreeBSD user (and Mac OSX) here, so I've only followed the systemd meltdown from the periphery. Is that really true about systemd and packaging?
Re: (Score:2)
Apparently so. See http://0pointer.net/blog/revis... [0pointer.net] .
Re: (Score:2)
KDE doesn't depend on systemd. KDE runs on FreeBSD, which doesn't have systemd. KDE also runs on Windows.
Re: (Score:2)
> But udev doesn't depend on systemd, so your slippery slope is not very slippery.
It only has to be a little slippery, it's the steepness that lets people fall in. See the kdbus and similar components for the ongoing integration of udev with systemd.
Re: (Score:2)
systemd has already broken the kernel repeatedly, a decade of log collection and analysis tools that I personally use, decades of cross-platform tools, decades of network configuration tools, and now it's trying to replace "su" and "/etc" to create a "stateless Linux". I'm afraid that it's a system management tar baby, adhering to every system component that it touches and leaving them snarled in sticky debris that is difficult to wash off.
None of that is really true. If you want syslog, just install syslog, and uninstall journald, systemd is modular, and you can pick and choose, you can even run syslog AND journald.
Similary the su ability is a new method you don't need to use. It is only a special case of new shell with a changed user that maintains all the most recent freedesktop variables.
Re: (Score:2)
> systemd's policy to drop them makes servers less secure
They have _replaced_, systlog with kernel resident binary logging utilities. This has advantages: you can generate monitoring from the kernel, itself, at boot time, before syslogd is running.
The big concern I've encountered is that systemd replaced stable, legible, parseable, well understood log output with t published but quite unique log format which no other tools in the world knew how to read. It wasn't necessary for enhancing init script mana
Re: The Linux community is destroying itself. (Score:2)
Please provide a link to a systemd document explaining their "policy to drop syslog messages".
On RH/Centos, systemd forwards to syslog by default, but systemctl status dhcpd (or similar) is very handy.
Re: (Score:3)
I call FUD.
Apparently systemd only consumes log messages by default. If you're looking for forensic analysis or troubleshooting, you can turn on forwarding to a normal syslog service like rsyslog or syslog-ng.
Re: (Score:2)
Examples of systemd breaking the kernel include the "debug" logging option, and the inevitable failures of such a complex weave of components killing PID 1.
https://bugs.freedesktop.org/s... [freedesktop.org]
http://ewontfix.com/14/ [ewontfix.com]
Unfortunately, "running syslogd in parallel" doesn't work well as new daemons or services are compiled for one or the other. And I'm afraid the code to integrate with systemd logging is a tar-baby: it
Re: (Score:2)
Well it is the community that just took the easy path and created a dependency on them.
Not really. Linux distros have long been divided into to major factions, the Red Hat faction and the Debian faction, plus some other sizeable mostly-unaligned groups (Slackware, Arch, Gentoo). These three factions still can't agree on even a package manager for some strange reason, even though it'd make things a lot easier to have this standardized. Debian is in no way dependent on RH. Ubuntu is dependent on Debian h
Re: (Score:2)
What distro features KDE5? I'm not aware of any.
If you're trying out alpha software, then I don't think it's at all fair to complain about issues like this. You can't expect a good out-of-the-box experience with something that isn't ready for prime-time.
All the KDE distros I know of are still using KDE4. Remember, they had this problem before: a bunch of distros switched to KDE4.0 way too soon (there's disagreement over whether the KDE team claimed it was ready for use or still in beta), and it was a dis
Re: (Score:2)
As a long time Linux user, I'm dumbfounded by how the Linux community has basically turned on itself over the past 5 years.
It's not Microsoft, nor SCO, nor Apple, nor any other external entity that's destroying the usefulness and practicality of Linux. It's the Linux community, as a whole, that's doing this!
Systemd is the obvious example of this. Never have we seen a piece of software so divide and devastate the Linux ecosystem.
Go here: http://distrowatch.com/ [distrowatch.com]
Then come back and blame this silly fake disaster on systemd.
Re: (Score:2)
I think you did not understand his point.
Re: (Score:2)
I think you did not understand his point.
What's "the Linux cummounity if not roll your own if you don't like it.
DIvision is exactly what linux is all about. If you don't like something, fork it. If the folks who start going apeshit the second systemd is mentioned were to fork it, instead of the incessent whining, they wouldnt have anything other than to brag about how superior their computig experience is, and eventually the distros with systemd would become mere footnotes, as it's ruinous qualities will just cause it to fail.
RIght?
Re: (Score:2)
still off topic
Re: (Score:3)
My theory
We saw this in Windows in 2006.
Vista scarred users soo much they freaking stuck with a 12 year old OS after Windows 7 cleansed all the messes of Vista. Some were happy to get Windows 7 and it had measurable marketshare from sites back on the RC days lol. The other half ... XP WORKS FINE!! CHANGE FOR THE SAKE OF CHANGE NA NA.. etc.
Well SystemD tried to be what Init failed to do on a modern system. Event driven Macbooks with startupD could sleep in one time zone and wake in another. :-) Init can't d
Re:The Linux community is destroying itself. (Score:5, Insightful)
You, and people like you, exhibit the mentality and attitude that is responsible for the ongoing destruction of Linux.
Long time Linux users who use Linux for critical systems repeatedly describe the problems they've encountered with certain pieces of software, such as systemd and GNOME 3. Instead of listening to these users and trying to understand their problems, you and your ilk deny that these serious problems exist, and then attack these users for daring to mention these problems (by wrongly accusing them of "trolling", for example).
Treating users in such a horrible way never ends well. These users just won't put up with it. The most talented, experienced and knowledgeable Linux users have already moved to FreeBSD, or are in the process of doing so. These are the kinds of users who are needed the most by Linux; they're the ones who push for its adoption and use. Linux won't disappear all at once, of course, but a gradual decline is inevitable now that these critical users have been forced out.
We only need to look to Mozilla and Firefox to see what happens when users are treated like dirt. Firefox was once a very popular web browser, with well over 30% of the browser market. But then the Firefox developers stopped listening to what Firefox users wanted, and instead forced unwanted junk on Firefox's users. Even worse, the Firefox developers did not listen to the objections of Firefox's users to these unwanted changes. After several years of treating Firefox's users so poorly, we can see the awful results. Firefox is now under 10% of the market. The users who propelled Firefox to success have moved on to greener pastures, which even include modern versions of IE, as unbelievable as that may be. Now Firefox is seen as a joke browser, rather than the powerhouse that it once was, just a few years ago.
I sure hope that what we've seen happen to Firefox doesn't happen to Linux, but things aren't looking encouraging. There are just too many people like you, who are incapable of seeing the big picture, and more important, incapable of listening to the users of Linux. Not listening to these users and their concerns is perhaps the most harmful thing that can happen to Linux as a whole.
Re: (Score:2)
We only need to look to Mozilla and Firefox to see what happens when users are treated like dirt. Firefox was once a very popular web browser, with well over 30% of the browser market.
The problem with using that as an example is that Linux doesn't have 30% of the desktop PC market, it barely has more than 1%.
It never was popular to begin with.
Re:The Linux community is destroying itself. (Score:5, Insightful)
Long time Linux users who use Linux for critical systems...
Oh hey, that's me.
...repeatedly describe the problems they've encountered with certain pieces of software, such as systemd and GNOME 3.
Well, yeah. I'm a cranky old fart.
Instead of listening to these users and trying to understand their problems, you and your ilk deny that these serious problems exist...
Now wait just one Turing-completing minute there!
The problems aren't serious. They don't break my critical systems, because I'm not going to be deploying systemd into production until I've tested it thoroughly. My old init scripts will get a wrapper or a rewrite to fit the new OS as needed, but the software interface won't change very much at all. Now, if you want a serious problem, find a vulnerability in a basic system utility, like bash or OpenSSH. Those problems are already out in the wild, deployed to production systems. When a new one of those problems is found, there's a notable increase in the use of profanity around my desk.
A new startup system, or a new package format, or a new thing that does this thing different than how the old thing did that thing... none of those bother me. I'll wait, running my old-but-stable critical systems, until you short-tempered folks settle on exactly what you want to do. I'll then work around whatever issues remain, because that's my job. I'm a sysadmin.
Re: (Score:2)
No. It gives you license to want to murder the previous sysadmin who didn't bother to learn the system he was using.
On the other hand, if it's only "poorly-configured" because it doesn't conform to your standards, but does fit the design Ubuntu intends, then you have nobody to blame but yourself.
Re: (Score:3)
So how is that different from when the init script goes and fubars itself, or shits all over a log and you can't fix it? Or what about the kernel itself? What if your CPU is really a small explosive device, planted to sabotage your mission-critical systems? I guess you should go fire everyone who ever puts anything into mission-critical systems, because they might fail sometime.
I am not suggesting that critical failure is acceptable, but I do argue that the expertise, testing, and trust of a new system sho
Re: (Score:2)
Treating users in such a horrible way never ends well. These users just won't put up with it. The most talented, experienced and knowledgeable Linux users have already moved to FreeBSD, or are in the process of doing so. These are the kinds of users who are needed the most by Linux; they're the ones who push for its adoption and use. Linux won't disappear all at once, of course, but a gradual decline is inevitable now that these critical users have been forced out.
You can really see this in Ubuntu and the Ubuntu Forums. Back a long time ago... :) There were many active Ubuntu LoCos and knowledgeable people on Ubuntu Forums. Then the LoCo requirements got weird, and regions got arbitrarily changed. (Like Texas being one region since it was one state... Forget the fact that Dallas is closer to Chicago then El Paso.) And the LoCo community started to fall apart. Then Ubuntu Forums got hacked, and they went to the Ubuntu universal account that would not keep you lo
Re: (Score:2)
Re: (Score:2)
P.S. I assume you meant "tail | grep" not "grep | tail" !
"grep | tail" works better IMO
Re: (Score:3)
You have got to understand one thing : Linux is the playground of Red Hat. From top to bottom Red Hat does and the others follow or die. The idea that there is freedom in the open source movement is pure illusion. He who has control of the infrastructure components has control of linux. The other guys are just small fish. Even Ubuntu doesn't go anywhere without Debian, and Debian doesn't go anywhere without Red Hat.
Ironic that you post this in an article that is in no way about rpm... :) I think it is more about developers that have become user unfocused. The "We know what they want more then they do" mentality. That never works well.
Re: (Score:3)
I think it is more about developers that have become user unfocused. The "We know what they want more then they do" mentality. That never works well.
It works quite well *if* you have a very good designer/innovator. Steve Jobs was arguably the best ever at building a product people didn't know they wanted until they saw his version of it.
The problem is that very few people are good at design, and most are really, really bad. When that happens we have to wait until market forces play out and the design fails.
Re: (Score:2, Troll)
You're why we don't have flying cars yet.
Oh don't be so dramatic. The real reason Linux is holding up flying cars is shitty drivers.
Re: (Score:2)
You're why we don't have flying cars yet.
Oh don't be so dramatic. The real reason Linux is holding up flying cars is shitty drivers.
If they would just share the API so we didn't need a flying car binary blob...
Re: (Score:2)
This whole systemd fiasco has caused a boatload of infighting, dissension among what should be cooperative members and teams, and it makes the process of administering Linux systems that much harder.
There is no need for a Microsoft conspirator to produce this outcome. The linux community, filled by zealots who *believe* in "Right Things" is completely responsible for its fate. Any change to core components will result in a mess.
Extremely good changes will cause little problems (only some whining) ; reasonably good changes with little drawbacks will cause havoc. And instead of working together with authors to improve shortcomings, they will just waste their time (as well as the time of the authors) to
Comment removed (Score:5, Interesting)
Re: (Score:2)
Microsoft didn't shun back from destroying the then largest mobile phone vendor, Nokia.
Nokia destroyed itself by trucking on with crusty Symbian for too long. The Microsoft deal happened long time after that.