Slashdot Mirror
Shuttleworth Says Snappy Won't Replace .deb Linux Package Files In Ubuntu 15.10
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."
The functionality will be built in to the next version of systemd.
Will Launchpad build the snaps after it builds the debs?
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.
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.
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.
http://saveie6.com/
Fundamentally it's a chicken and egg issue. GNG is Not GNU, but GNG is not GNG.
https://www.google.com/search?...
'The nice thing about GNG is that it's completely GNUtard-free, GNG said.
"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.
"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.
Just cruising through this digital world at 33 1/3 rpm...
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
world was created 5 seconds before this post as it is.
I swear to god, there are times when I think that Pottering is a secret, deep-cover plant by Microsoft whose job is to disrupt the Linux community, fragment the OS by introducing shit like systemd, and generally make a hash of the Linux ecosystem.
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. I'm no dev guru or Linux wizard, but even I know that swallowing stderr messages and mucking with long-time, well-established syslog formats is a Bad Thing.
If he's not a secret, deep-cover plant owned and directed by Microsoft, he should be. Microsoft should be paying him handsomely for all the trouble he's caused.
* No, I don't think he's really a Microsoft operative, but damn...he may as well be.
Just cruising through this digital world at 33 1/3 rpm...
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.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
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...
It's their yummy new almond flavoured product.
All those moments will be lost in time, like tears in rain.
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?
I actually what you're smelling are lolmonds, a newer relative of almonds.
Mod me down, my New Earth Global Warmingist friends!
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 with your distro for not including it. What your distro decides and decides not to bundle is not the fault of systemd.
Installing syslog on such a system doesn't log systems messages unless you reroute all of them away form systemd/journalctl.
Newsflash: you cannot have two logging daemons listening on the same socket and receiving the same system calls. If you want two logging daemons, one will need to forward that information to the other. JournalD does this, syslog does not, hence the current arrangement where journald forwards logging information to syslog.
But, do carry on insinuating that my log usage or viewing habits are inferior or inadequate because they use the preferred methods of the last 20+ years, rather than your preferred and totally new method. While we're at it, how about the fact that the log file itself is now formatted differently and is binary encoded rather than text. No, that doesn't break anything, 'except old people stuff'.
Wow, defensive much? Whether or not they are inferior or inadequate depends on what you are doing. They are for some people, and journalctl is the solution. If you don't want to use it, that's your choice. Do continue using your method of 20+ years, but you will be missing out on the advantages that journald provides.
As for dependencies, log dependencies are broken, despite your childish refrain of veiled insults. Startup scripts are broken. and the list of broken projects/packages/scripts goes on and on.
If there is a new init system, then old init scripts will be have to rewritten to use it. There is a compatibility method to ease the migration, but a migration will still be necessary eventually. I'm not sure why this is so shocking to you. Your argument basically boils down to "systemd is bad because it isn't sysvinit." If you don't see why that is a ridiculous argument, I don't know what else to say.
These facts aside, you're still arguing with insults.
I am not doing that at all. I am explaining to you how systemd works. You are the one taking it as an insult.
You're not presenting arguments that demonstrate any actual value of the new system/way.
Why do I need to present the arguments in favor of systemd, again, when they have already been made repeatedly elsewhere? At any rate, systemd advocacy is not the purpose of my reply. I am just explaining to you how it works and dispelling the myths that you are perpetuating.
All you've said, like I claimed in the GP, is that my 'unwillingness to accept the new way is because I'm inadequate in my use of Linux and that real users like yourself need all this old shit gone because it's old'.
Nowhere did I say anything like that.
I still say that this is not a valid or logical reason.
It's a good thing that is not one of the reasons then. There is a pretty good summary here (since you insist),
https://wiki.debian.org/Debate...