Slashdot Mirror
Adios Apt and Yum? Ubuntu's Snap Apps Are Coming To Distros Everywhere (arstechnica.com)
An anonymous reader shares an Ars Technica report: Ubuntu's "snappy" new way of packaging applications is no longer exclusive to Ubuntu. Canonical today is announcing that snapd, the tool that allows snap packages to be installed on Ubuntu, has been ported to other Linux distributions including Debian, Arch, Fedora, and Gentoo among others. To install snap packages on non-Ubuntu distributions, Linux desktop and server users will have to first install the newly cross-platform snapd. This daemon verifies the integrity of snap packages, confines them into their own restricted space, and acts as a launcher. Instructions for creating snaps and installing snapd on a variety of distributions are available at this website. Snaps can exist on the same system as either deb or RPM packages. Snaps aren't the only new package manager for Linux distributions that aims to simplify installation of applications. There's also AppImage and OrbitalApps.
Hay, finally a universal app for Linux!
Adios to tried and true package managers, hello dependency and network/firewall hell as you try to resolve conflicts between the different sources?
In the year 2016, where can I, a long time Linux user, get a decent UNIX-like Linux distro?!
What I mean by that is a Linux distro that follows the UNIX philosophy of simplicity, doing one thing well, openness, and modularity.
All of the major distros today, including conservative ones like Debian, are rife with systemd, GNOME 3, now this "snap" crap, and all sorts of other shenanigans that violate the UNIX philosophy.
I don't want to use a goddamn relic like Slackware, either. I guess what I want is Debian, but just before systemd was forced on Debian users. So a distro that's sensibly conservative, that's reliable, that works, and that follows the UNIX philosophy.
And don't even bother suggesting Devuan. It's a terrible, terrible joke of a distro in my experience. Conceptually it's what I'd want, but in practice I've found it to be a total shitfest.
At this point I don't think I'll have any choice but to use FreeBSD. Yeah, it's not Linux, but I don't think that I even care about using Linux at this point. I need a UNIX-like system, and if FreeBSD can deliver (and all of the evidence suggests that it can!) maybe I should just say to hell with Linux and use FreeBSD instead.
When I first tried Linux, I didn't understand the repository system. I had been so used to the Windows .exe files I didn't understand downloading my programs from a single secure repository. One day, it clicked. The repository system is so much better. No more worrying about compatibility, or someone adding malicious software to my programs. It all comes from one secure repository and is known to be compatible with my system.
In fact, that model works so well, Apple and others now use the same model. They call it an "App Store". I've even heard rumors that Microsoft wants to switch to this model
So, why is Linux going back to the old, and inferior way of doing things?
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
1) DEBs and RPMs aren't going anywhere; they serve different functions from Snappy Core. Snaps are better for servers that require zero downtime because they prevent ABI breakage as packages are updated asynchronously. DEB and RPM are better for desktop, mobile, and less-important servers because they take up monumentally less room (because you don't have to have a million versions of the same dependency installed at the same time).
2) As TFS indicates, Snaps can coexist with all the other packaging tools (apt, dnf, yum, zypper, slapt, portage, pacman, etc.).
3) A large percentage of the Linux community are [a] too suspicious of Canonical to ever adopt any of their technologies and [b] conservative to the tried-and-true methods of doing things. apt will probably live forever on account of that.
...that the answer to any question posed in a headline is "No".
I'd be all for a single consistent package management system for Linux that everyone could get behind. This isn't that. This is just a third option everyone's going to have to deal with.
Et tu, Gentoo? Then fall Linux
Snapd seems to be spreading with the same wildfire potential that systemd did. I hope I'm cringing over nothing in this case and snapd will only be an optional package management system (so far it sounds like it). But I'm leery. Systemd fractured a lot of distros with the "my way or the highway" attitude they had over it. I managed to avoid it on my servers where just about everything run on it right down to the compiler time sharing are background user processes. If even more distros move on pushing snapd in the same way it may finally be time for me to look into one of the Beasties to migrate to... either way, there's going to be a lot of workflows that will need analysis for migration one way or the other.
We all know this technology won't really be mature until "snap management" is fully subsumed and integrated into systemd, where it belongs.
Welcome to the Panopticon. Used to be a prison, now it's your home.
>> "Snaps aren't the only new package manager for Linux distributions that aims to simplify installation of applications. There's also AppImage and OrbitalApps."
Said without irony.
I been riding my old grey mare for 40 years and she works for me, and along come all these kids in those new fancy things called motorcars, i am keeping my mule until i die
Politics is Treachery, Religion is Brainwashing
And i think i speak for us all when I say I'll be in the cold cold ground before i ever trust some bull-shit packager repository more than portage. Shuttleworth can eat my ass like groceries.
Good people go to bed earlier.
You don't want to switch. Nobody is saying use Snappy Core exclusively, it's not designed for that.
The "adios" in the headline would seem to imply that as a rhetorical, at least.
Its main purpose is for servers that require zero downtime, where you want to upgrade application X and/or its dependencies without breaking even the smallest functionality of application Y.
... -_- No server "requires" zero downtime. Anyone who put that into a req. document should be shot. You get more 9's by duplicating and providing physical, logical, and temporal redundancy. And we've gotten high redundancy for servers just fine using RPMs, thanks. (And .deb's, I assume.) Acting like there are no solutions out there is ludicrous. But then, a lot of the last six years of Linux-land have been like that.
Hire a Linux system administrator, systems engineer,
Seems like all my /. posts have been crabby, complacent, old-hat UNIX/Linux sys-admin ranting as of late. F me I need to lighten up...
With that out of the way, I do have to say: Who said that installing packages was hard on a *NIX platform that we needed snapd to solve this? I'm sorry, I really think package repositories like apt/yum are gosh-darn God-sends when set up, populated, built and maintained correctly. I use them in-house and it really makes deployment, configuration management, deployment and all that stuff most people care about, well, easy. Why would I need 'another' package manager to sit 'alongside' my existing one to do updates? In regards to RPM based distros, isn't that what drpms and alike were suppose to solve? And not to mention you can checksum, roll-back, push/pull version specific, ect.
This just sounds like yet another shitty reinvention of wheel idea with YOLO douchey distro dev backers that I'm going to see take over yet another great part of Linux distro's as we know it --- I thought enough was enough with systemd.
Its main purpose is for servers that require zero downtime, where you want to upgrade application X and/or its dependencies without breaking even the smallest functionality of application Y.
I disagree, snapd is Canonical's attempt to bring an android/ios like 'app universe' to their linux OS. Unfortunately if it succeeds, I also forsee it bringing the in-app advertisements and micro-payments mess :(
It is trivial to avoid GNOME in every distro I've looked at. I really dislike GNOME 3, and as a result I avidly avoid anything by the GNOME team. I've had no problem doing this! It is really easy to never touch GNOME.
SystemD is not a deal breaker for me, but I would avoid it if it were easy to do so. It does not appear to be. Slack and Gentoo can function just fine with any other init system, and Devuan will hopefully eventually scratch that itch. If the requirement is "no systemd", you are ultimately going to be doing some kind of integration right now. I figure at some point there will either be a distro without systemd, or systemd will have had enough fixes shoved down its throat that using it is fine.
I think ultimately the community has been taken by surprise at the massive surge in most distros toward systemd. Different distros have all kinds of diverse things under the hood, different package managers, different locations for stuff, etc. But systemd just swarmed over everything, it seems really odd.
There's no contradiction.
1) Systemd and GNOME 3 aren't the only "modern technologies" out there. They are among the most anti-UNIX-philosophy ones. There are other modern init systems and desktop environments that do follow the UNIX philosophy, we just see the major distros treat them as second-class citizens, although they're typically superior to systemd and GNOME 3.
2) The point of using a mainstream distro is to get access to the wide community support network and the benefits it brings, including more testing of releases and quicker bug/security fixes.
3) The whole point of using a Linux distro is to avoid having to roll your own! In the past there used to be choice among the major distros. Debian is what you used when you wanted a system that worked. SuSE is where you went if you liked KDE. Ubuntu is where you went if you wanted a Windows-like experience. Fedora is where you went if you wanted to subject yourself to Red Hat-produced shit.
I know you're intentionally ignoring the real problem here: the fact that the major Linux distros have converged to the point where they're nearly identical. Worst of all, they've chosen to converge on software that exhibits a very anti-UNIX approach, such as systemd and GNOME 3.
Today, a modern Linux distro installation is closer to Windows than it is to anything resembling UNIX. The Linux userland has become a cheap imitation of Windows in so many ways, from the GUI down to the init and service management systems.
If you want a Linux distro that doesn't use systemd, you have a lot of options. But your complaint seems to be that that most of the Linux community has moved away from your preference. Well I'm sorry princess that you're not in the majority anymore, so either get comfortable in the minority, get your hands dirty with the majority, or do the work getting things exactly how you want them. But I'm not terribly sympathetic to your complaints if you're sad that the rest of the world isn't 100% empathetic to your desires, sparing you from the work of making your own perfect distro to your preferences.
At least I can understand the systemd complaining, because most distros don't support sysvinit or upstart anymore. But I really don't get the GNOME 3 bitching. I hate it just as much as you do, but literally every single one of the big distros (so that's Ubuntu, Fedora, openSUSE, Debian, CentOS, Arch and Gentoo) support alternatives.
We don't even have anything as capable as apt and yum. Meanwhile Linux is moving ahead even further.
Its main purpose is for servers that require zero downtime, where you want to upgrade application X and/or its dependencies without breaking even the smallest functionality of application Y.
I disagree, snapd is Canonical's attempt to bring an android/ios like 'app universe' to their linux OS. Unfortunately if it succeeds, I also forsee it bringing the in-app advertisements and micro-payments mess :(
There will only be in-app advertisements and micro payments if the developers put them in. If they do so, blame them, and not the format of the package they decided upon.
"confines them into their own restricted space"
I'd like to know more on this. What restricts them? Are they, like, restricted by SE Linux to only act in their own little space, or is something outside the kernel doing this restriction? Whenever I hear about these types of access control, I always get concerned. All these sandboxes and jails have ways out of them normally, and the more obscure, the longer they wait, and their mere existence and claims makes people trust the supposedly protected applications way more than if they knew it was just going to execute with whatever permissions their user has anyway.
I seem to recall a big panic over some fundamental security flaws in Snaps, something about them leveraging the worst ways X11 is written. Unless it's some convoluted way to try and progress what seems to be the IPv6 of the display server world (Mir / Wayland), isn't spreading this thing to other distros a bit of a bad idea?
Old does not mean bad.
Slackware is old, but certainly not a relic. And boasts a stability track-record that most other distros simply do not match. It not only adopts the unix philosophy, but embraces it so fully that the only comparable distros to it in this regard that I know of are Arch and Gentoo. Gentoo is a bit of a bitch because you have to compile everything, which can take a long time when doing system updates, and Arch is regretfully somewhat less stable than Slackware because it updates its packages so frequently (although if you are willing to risk some stability in the interests of running the bleeding edge versions of all available packages, Arch might be right up your alley).
But slackware is still being actively maintained, despite having longer release cycles than most other distros. Slackware is at a release candidate stage for 14.2 in slackware-current at the moment, and I'd be honestly quite surprised if 14.2 wasn't released sometime this summer or fall.
File under 'M' for 'Manic ranting'
Too lazy didn't Google. Is there a great benefit over command line apt-get install? apt is so crazy easy that I decided to battle brew and fink on the mac in a quest for the same goodness on my Mac only to be sorely disappointed.
What we actually see is that the Linux distro maintainers have moved away from the preference of the Linux community.
That's why there has been such a huge uproar about systemd. Systemd is not what Linux users want. It's what Red Hat wants.
As we saw from the debacle around forcing systemd into Debian, systemd may make the maintainers' lives easier, but it absolutely ruins the Linux experience for the users.
People using a Linux distro in the first place don't have time to be rolling their own. So they're moving to FreeBSD, OS X, and even Windows, because Linux distros now deliver an experience that's worse than all three of those.
The fact that Linux is at, what, 1% or 2% of the desktop market, despite the massive opening that Windows 8 and even Windows 10 have left for it, just goes to show how modern Linux isn't what people want.
The resurgence of FreeBSD, fueled mainly by Linux refugees, further reinforces the idea that modern Linux isn't what server users want, either.
I really hate to say this, but traditional Linux distros are all withering away. They're a lot like Firefox. They have some momentum which makes them appear relevant, but the long term trend is a very negative one, with them becoming irrelevant not too far into the future. At least Firefox had 30% or more of the market at one point. Linux distros never got that far!
Traditionally I've had to use iptables, but if you say it's easy. I'll give it a try. Let's give my home network I try, could you explain to me how to do this...
I have three physical network adapters, for simplicity, I will use traditional Linux interface naming conventions.
eth0: PPPoE for Internet connection 1
ppp0: Internet connection 1 tunnel
eth1: DHCP, single IP for Internet connection 2
eth2: has four vlans.
vlan1: offers DNS, NTP, for 172.16.10.x network, allows direct communication to vlan2 and vlan3 (expecting everything to be statically assigned here), offers Internet connection 1, if internet connection 1 stops working, switches over to Internet connection 2. I'd also like to see example of forwarding UDP and TCP of a given port to a server on this network.
vlan2: offers DHCP, DNS, NTP for 172.16.11.x network, allows you to communicate directly with machines on vlan3 and vlan1, offers Internet connection 1, if internet connection 1 stops working, switches over to Internet connection 2
vlan3: offers DHCP, DNS, NTP for 172.16.12.x network, allows you to communicate directly with machines on vlan2 and vlan1, offers Internet connection 2, if internet connection 2 stops working, switches over to Internet connection 1.
vlan4: offers DHCP, DNS, NTP for 172.16.12.x network, does not allow communication with any machines on any other vlan. Internet traffic is throttled to 2mbit download, 2mbit upload. This defaults to Internet Connection 1, if internet connection 1 stops working, switches over to Internet connection 2.
The firewall must drop packets from wrong IP addresses for the wrong vlan, ie: drop someone statically setting them-self as 172.16.10.12 on vlan4, since vlan4 is only supposed to use 172.16.12.x.
The system's default Internet connection should be internet connection 1, if it's not working to switch to 2.
Also, I'd love to hear how you would handle the DHCP setup for different IP ranges on different vlans.
I welcome to hear your reply.
Change is certain; progress is not obligatory.
The usage statistics of all the major Linux distros and the financials of the major Linux companies (Red Hat, IBM, SUSE, Oracle, Canonical) don't seem to suggest that at all.
I see a lot of anonymous cowards on Slashdot being loud against systemd, but in the real world it's just another tool that people use, no different than the GNU utilities or APT.
The same anonymous cowards are proclaiming some kind of exodus to the BSDs, but their usage statistics don't really support that either.
I do apologize, I messed up vlan4 slightly, here are the amendments:
vlan4: offers DHCP, DNS, NTP for 172.16.13.x network, does not allow communication with any machines on any other vlan. Internet traffic is throttled to 2mbit download, 2mbit upload. This defaults to Internet Connection 1, if internet connection 1 stops working, switches over to Internet connection 2.
The firewall must drop packets from wrong IP addresses for the wrong vlan, ie: drop someone statically setting them-self as 172.16.10.12 on vlan4, since vlan4 is only supposed to use 172.16.13.x.
Change is certain; progress is not obligatory.
That run in some sort of 'restricted' space? Fine. But what about all the other components of a Linux distro that aren't apps, can't run in a restricted space and will never be ported to the Snap model?
I think apt, yum and their kin will be around for a long time. Snap sounds like an environment written for people like the ones that thought Microsoft Windows Metro apps would be all that users would need.
Have gnu, will travel.
Dynamic linking is for the weak!
It is hilarious, once upon a time it was commonplace for *every* library to be available static linkable and dynamic linkable, and the toolchain would have a simple flag to let the build decide if it should produce a static or dynamic binary.
They decidid this was a 'harmful' approach and by and large the toolchains removed the easy way to statically link things to force dynamic as it was seen as better.
Now you have snappy and singularity and go... all saying 'screw dynamic linking, static link or fake static link!'
XML is like violence. If it doesn't solve the problem, use more.
The headline is spectacularly stupid. Nobody but nobody thinks that every package will/should be a snappy. It's basically a way to get some package here and there installed when it is not convenient to try and get a whole pantload of dependencies installed - perhaps because these dependencies as shared libraries might then conflict with some other packages you have.
I see it as less needed for a bleeding edge rolling distro like Arch, but it sure might come in handy for somebody stuck with CentOS6, dripping with prehistoric versions of everything, all of them interlocked in their obsolete cluster foxtrot.
So are snaps more powerful, or faster, than what we had before?
If not, your analogy breaks down.
Snaps, containers, or whatever could be very helpful for small projects that don't have a team of packaging gurus. There are hundreds of useful apps collecting dust on github or on the developer's hard drive because packaging requires too much expertise. There are four or five different packaging systems each with their own steep learning curve. Add to that the three major init systems to support and the effort to distribute your project can exceed the work it took to develop in the first place.
I see a lot of anonymous cowards on Slashdot being loud against systemd, but in the real world it's just another tool that people use, no different than the GNU utilities or APT.
I'm not an AC and I'm actually in agreement with most of the people against systemd for reasons that have already been discussed ad nauseum.
Does SysVinit need to be updated or replaced? Probably, depends on what you want or need. Is systemd the answer? Oh, hell no. There are plenty of other alternatives that don't risk breaking the system to the extent that systemd does.
I'm pretty sure that the only reason systemd got off the ground is because GNOME3 required it. It is the epitome of "dependency hell".
When politicians are involved, everyone loses.
I could get behind this for some programs - especially games.
It might be a little space-wasting for "core" stuff.
The preceding post was not a Slashvertisement.
I think ultimately the community has been taken by surprise at the massive surge in most distros toward systemd. Different distros have all kinds of diverse things under the hood, different package managers, different locations for stuff, etc. But systemd just swarmed over everything, it seems really odd.
No, forum posters were taken by surprise. Fedora started using it in Nov 2010 and set it default 6 months later. RHEL introduced it 3 years after Fedora (2014). Debian had a massive 4 months long discussion complete with web pages detailing the pros and cons of each init system before coming to an agreement in early 2014.
Really though, the only actual problem I ever had with it was that on MY PC, I had removed a dead drive and never replaced it. When the SystemD update happened, it just hung. Ihe earlier versions of SystemD never told me why the boot was just hanging for several minutes. An later update had the boot process show me that it was hanging on the drive mounts. It turns out that my old init system was silently failing to mount the drive and then moving on.
I happen to really like Gnome 3. I have had no problems completely avoiding KDE, LXDE, Unity, or what have you. Yay, Linux!
(Score: -1, Stupid)
At least I can understand the systemd complaining, because most distros don't support sysvinit or upstart anymore.
That's just horseshit, distros still support SysV init. Why are you still recycling these lies, even after they've been refuted again and again?
No, package dependencies don't mean you have to use it, it means that it will be installed because nobody competent actually has a use case for removing the dependency and managing the extra packages. (Just pre-empting the usual follow-up lie)
At least I can understand the systemd complaining, because most distros don't support sysvinit or upstart anymore. But I really don't get the GNOME 3 bitching. I hate it just as much as you do, but literally every single one of the big distros (so that's Ubuntu, Fedora, openSUSE, Debian, CentOS, Arch and Gentoo) support alternatives.
Support is a vague term. I've used Debian with several desktop environments. XFCE and Cinnamon don't have near the polish that was put into GNOME 3. It's clear Cinnamon on Debian is an afterthought. Supported, and that's where it ends. The Debian team put most of their effort into GNOME
Conversely, Cinnamon on Mint is wonderful. It's clear the Mint team put a lot of time and effort towards making it a great experience.
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
Sorry, that doesn't cover what I requested, you have failed the task, completely.
Believe it or not, I actually do have two Internet connections in my house, if this was a datacentre, I'd have some fancy router instead of a random Linux box sitting under my desk with a bunch of manually written iptable rules that I struggle with each time.
I didn't even go to the extent of requesting the uPnP crap for each Internet Connection, or mention the amprnet vlan with it's amprnet gateway configuration; which was such a headache for me to figure out how to integrate into this.
Literally everything runs on major Linux distributions too, you're not making a convincing argument.
I'm waiting for the ease of use that genuinely matters, being able to turn on and off a firewall in a GUI has literally been in most distros for years, it's so old, you can find it in the first versions of Mandrake and Coral Linux. It's upsetting that after all this time, Yast's Firewall module still doesn't compare to Firewall Builder's usability, reconfigurability and flexibility, then you tout a shoddy GUI in comparison that is less flexible and less user friendly (it doesn't even have a user friendly wizard). Sorry, but feck off with your late 90s technology, it's clear you're living in the past and have no vision for the future nor even an understanding of the technologies that are currently even out there.
Change is certain; progress is not obligatory.
There are plenty of distributions that don't use systemd. See link, but quite a few of them are based on Slackware and Gentoo. I use Void Linux personally.
My main dislike is just the scope creep, lack of choice (you used to be able to choose what login manager, device manager and system logger you wanted), and the mentality of systemd developers where they believe that one solution is just "better" and everyone should go with that route.
I'm still using the same toolchains as before, and I can still do all the same things as before, plus new things.
Whatever tools you're using, know this: there are other ways that exist in the world. Don't listen to them, you never have to change paradigms if you don't want to. Now, SysV sucked in almost every way, but it was the best we had. No longer true. But it is still there if you like it. All the old tools still work. Some people even hate dbus, but mostly not people who would otherwise be using SysV IPC.
If it works, don't change it. If it sucked from the start, change one time. Like switching from sendmail to postfix, or oracle to postgres. You only have to change one time. foocc to gcc, csh to bash, etc. And I liked csh. If I liked ksh, I'd still be using it.
Disclaimer: I've been using Gentoo since 2002/2003.
I agree that Gentoo's build process is cumbersome, especially on slower processors. This is a lot less of an issue now as compared to when I started using it in '02/'03, when I probably had five-year-old hardware then. Larger packages like Firefox and LibreOffice have always had a binary package to install. (On my 2002-era machine libreoffice would take something like 9 hours to compile.) My machine now, which is around 8 years old compiles this same package in a bit over an hour.
However, Gentoo also has another huge benefit, and that is customizing packages to your needs using USE flags. These toggle build-time options, so as an example, when heartbleed came out I was able to remove the offending tls heartbeat component using a USE flag and rebuild the package until a fix was made available.
Another thing I've discovered is if you have similar hardware and similar configurations you can tell portage to build binary packages. If you share this directory via nfs export you can instruct portage to favour binary packages when all use flags and other build-environment options are the same. This has saved my poor celerons on my MythTV frontends quite some compile time.
As we saw from the debacle around forcing systemd into Debian, systemd may make the maintainers' lives easier, but it absolutely ruins the Linux experience for the users.
I think your broad, all encompassing term "the users" is based on a whole lot of assumption. I never even noticed when Debian made the switch over on my desktop system. I didn't have any fiddly custom-configured services, it was all pretty much auto configured by Debian installs and updates. I didn't have to scream like a little girly and run around banging into walls until my ears bled, I just kept on using my computer.
Personally systemd never bothered me at all, and made the /. outrage seem ever more bizarre as the complainers got more an more carried away.
I usually have a spare box running FreeBSD, mainly something to do in times of boredom. I have had to spend much more time researching config files, tweaking and breaking FreeBSD until I got it right, even for seemingly quite simple tasks. Definitely a lot more complicated than just having Debian install what I want in a working state.
If I had a DeLorean... I would probably only drive it from time to time.
That's not the same. Many distros push GNOME as a default.
And like with android, i foresee a thousands ways to avoid them
They all have strong sales of their old versions without systemd (eg. RHEL6 and even RHEL5) because that's what the workstation software vendors demand.
You might be closer to the truth than you think. I was about to install snapcraft's ebuilds for Gentoo (snap-confine and snapd) but then noticed the systemctl calls and unit files. Adding insult to injury, they didn't bother to list systemd as a dependency. Hopefully there's not a real dependency on systemd and it's just a matter of writing init scripts, but in the meantime, thanks but no thanks.
This also sounds like a lot of effort and hoop jumping just to avoid dependency hell, you might as well just ship rpm/apt packages with statically linked binaries in them, the result would be just as bloated, and you wouldn't lose the conflict avoidance that would otherwise belost by running more than one package manager.
or is it just a NiH attempt at a Docker clone
Great, so when there is the next bug fix for openssl I'll get a 10 GB download with all the updates for the snap packages using the broken version. No wait, I'll get only a 1 GB download because most packages won't be updated and they'll keep using the vulnerable library. It's a black hat/spy's wetdream.
And a disk manufacturer wetdream too, with all that space wasted. I wonder if there will be at least a deduplication system, not to have the same libraries stored again and again in the directories of different packages. But I'm much more worried about the security issues.
Another thing I've discovered is if you have similar hardware and similar configurations you can tell portage to build binary packages. If you share this directory via nfs export you can instruct portage to favour binary packages when all use flags and other build-environment options are the same. This has saved my poor celerons on my MythTV frontends quite some compile time.
Also, use distcc if you have multiple machines.
Escher was the first MC and Giger invented the HR department.
You're also bullshit, and are not needed. At least real bullshit serves a useful purpose.
Free Software began as copies of something else. Anyone who thinks FS is or was intended to be innovative is a fucking moron.
Well my point was that the gcc toolchain started pushing hard *against* static linking, and nowadays there's a hard push *for* static linking (not from gcc mind you). Things keep swinging back and forth, seemingly each iteration having people totally forget why it went the way it is last time.
XML is like violence. If it doesn't solve the problem, use more.
Go read the article again. The systemd devs wanted to change the default option about terminating processes on log-out, which would break nohup. This default option can easily be switched back by distro maintainers. The debate was about whether the improved security of this default is worth breaking some of the users' expected behaviors of programs like tmux. It's not so simple as "systemd breaks hup".
Funny, thats precisely the argument used by Windows against Linux, that commercial success equated to technical quality. It would come as no surprise at all to learn that Poettering was a successful Microsoft plant to disrupt and destroy the Linux community from within. It worked with Nokia.
That makes no sense whatsoever. You're right that commercial success != technical quality, but that doesn't mean bad quality = more success and low quality = less.
Poettering works for Red Hat, who get all their revenues from Linux. Why the hell would they want to destroy Linux from within? Your conspiracy theory not only lacks evidence but doesn't make a lick of sense.
That should be "doesn't mean bad quality = more success and low quality = *more success."
And furthermore, if you want to talk about Microsoft destroying Linux, I would imagine they would use the same tactic as they did with SCO (i.e. fund their egregious lawsuit and use FUD to prevent people from switching off Microsoft). All of the insane anti-systemd FUD is more characteristic of Microsoft than systemd itself is.
My mistake. I was using "doesn't support" as shorthand for "doesn't ship sysvinit-core by default", but you're right, I was wrong.
The animosity came from Ian Jackson's insane anti-systemd trolling. He eventually resigned from the Technical Committee after recognizing the damage he caused to the community. However every time systemd was voted on, it was the chosen init system.
I been riding my old grey mare for 40 years and she works for me, and along come all these kids in those new fancy things called motorcars, i am keeping my mule until i die
That sword cuts both ways:
I've been driving cars to work now for 40 years and it works for me, and along come all these kids with these new fancy things called "nuclear jetpacks", I'm keeping my car until I die
You make the presumption that just because something is new it is better. This is almost never the case. Nine times out of ten, if you ignore the new stuff it will probably fizzle out and die anyway. That tenth one that succeeds will do so regardless of whether you fanboi for it or not.
I'm a minority race. Save your vitriol for white people.
What does this "improve" over yum? What killer features does it provide?
For example, let's take where I work, with over 170 servers and workstations, a couple machines of one user running debian, and a couple belonging to another user running ubuntu. And *EVERYTHING* else running CentOS. What does snapd offer me, what killer feature, that would make me want to change?
mark
Well my point was that the gcc toolchain started pushing hard *against* static linking, and nowadays there's a hard push *for* static linking (not from gcc mind you). Things keep swinging back and forth, seemingly each iteration having people totally forget why it went the way it is last time.
Well, then your point is complete hogwash, the gcc toolchain has no trouble at all with static linking, and it doesn't push for you to link one way or another. How would it even try? There isn't a GUI to pop up warnings, it doesn't ask you to please reconsider, so... what? What does it do to get in the way of static linking? When those of us who use gcc frequently want to static link, what barrier is in our way?
You're waving your hands and asserting there is a problem, but it doesn't exist. It not only doesn't "push hard *against* static linking" it doesn't even push at all. It is happy to do static linking. In fact, the exact same commands used to do static linking with the gcc toolchain in the 90s... still work. Makefiles from that era still work, including the bits about choosing static linking.
Ok, well, guess I should specifically say that the part of the toolchain is glibc. I couldn't remember the details so I did digging. The NSS functionality requires dynamic linking. If you request '-static' the result is... still dynamic linked.. So you cannot have a wholly static linked application (unless you build a special glibc yourself, that won't work quite right...) From a licensing perspective, LGPL makes static linking impractical. Nowadays you don't see the '.a' libraries generally built and distributed by defaults, *only* so. I generally recall 10-15 years ago this being a big general discussion point and folks being told 'just stop trying to make static binaries". The ecosystem has clearly in many concrete ways stood in the way of static binaries for over a decade.
Not I didn't say there is a *problem*, but a contradiction in the trends. There was a trend toward dynamic libraries more and more, and now there's a trend to squash all those benefits by auto-bundling libraries and/or finding ways to static link for the ability to ignore dependencies once again.
XML is like violence. If it doesn't solve the problem, use more.
That's all nonsense, I use static glibc at work frequently, there is no problem. The whole concept is still just horseshit. You admit you don't actually understand these things, so give it a rest. You didn't understand what you read, or it was just wrong. And LGPL is only a linking problem for mixing free software and non-free software, it doesn't have to do with the way that people actually use libraries. You can, for example, simply select a BSD-licensed libc. GCC won't care. You generally recall stuff from 10-15 years ago that you didn't understand then, and don't understand now.
You didn't claim that "there is a contradiction in the trends," you claimed that "by and large the toolchains removed the easy way to statically link things to force dynamic" and then you tried "my point was that the gcc toolchain started pushing hard *against* static linking" which was also not true.
There is no "once again." Things have been getting both static and dynamic linked all along. dynamic *is* better for commonly used system libraries that have stable APIs. Static linking is preferred for uncommon libraries that aren't going to be on the system, and for legacy crapware with conflicting APIs and no backwards compatibility.
And as for "Nowadays you don't see the '.a' libraries generally built" I can say:
# locate -r '\.a$' | wc -l
2698
Sure I do. You let slip that you're not a developer, so maybe that is the only reason you don't see which libraries get installed, and what toolchain options are available?
Who says they want to? I've seen plenty of stupid decisions made because someone who was a good talker or was shagging the PM supported them. And even that person might not actually want the outcome; they might be too fucking thick to realise what the consequences are.
You'd be surprised how much damage a single influential person in the wrong place can do.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."