New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Snap packages?
Hey guys and gals,
What is your opinion on Snap and its packages?
https://insights.ubuntu.com/2016/06/14/universal-snap-packages-launch-on-multiple-linux-distros/
Comments
snap vs flatpak
another battle "canonical vs GNOME/redhat" after unity vs gnome 3
I like the concept, but like IPv6 and systemd, it seems to be committee-designed and maybe a bit too complex for its own good. Also like IPv6 and systemd, if it takes off, we'll just have to accept that level of extra complexity. I call this the "touchless faucet" problem.
Hate to quote xkcd, but it is true. Realistically this will not be adopted by any distribution I would think unless it was new. It of course can and probably will be used as a simple solution to setting up applications not in repositories I would expect, though.
I'm curious what you consider so complex about IPv6. Larger addresses in hex notation or something else?
An obvious advantage of IPv6 is that it allows dead:beef in its addressing scheme.
The obvious disadvantage of IPv6 is that it's an engineers thing that kinda forgot that it should solve business needs and not just be nerdy cool. The mentality of "this is da shit, adopt it you peasants" is kinda inefficient, to say the least.
This:
Whoever architected this mess must not have had a reality check of "do we really need 51557934381960373252026455671 addresses per person on the planet?". Or had to have a 60 year old person read back an IP address to them. It's hard enough to get someone computer-illiterate to read back "one six nine period two five four" etc to realize they're not getting an IP from DHCP for whatever reason; I can't imagine what hell phone techs are going to have to go through after someone glazes over when presented with something like fe80::208:74ff:feda:625c.
Even expanding it to eight sets of a byte would have wedged us with 1.8e+25 addreses, easier for human beings to understand, easier to implement as an extension onto existing ranges. Give me a single compelling argument for IPv6 to be hex. This is not intended to be incendiary: I've not yet seen a single response for such that's not either "that's the way it is" or "because it's cool and you can spell shit!".
IPv6 is an abomination. Unfortunately like politicians, there's not much to do other than bitch about it.
This is not the same situation as running out of time on a 32-bit timestamp and switching things to 64-bit timestamps. Sure, like IPv6 it's a huge sledgehammer to solve a problem for the rest of human existence, but unlike IPv6, it doesn't actually reach the general population.
dead:beef:f00d:cafe:babe?
The obvious business need is the shortage of IPv4 addresses. That was the primary motivation and justification, a perfectly valid one at that. Private addresses and NAT only get you so far and come with an incredibly complex set of challenges themselves.
No, and that wasn't an architectural design goal.
This isn't a terribly strong argument against 128-bit addresses versus 32-bit numbers versus X digit telephone numbers or an X character license plate or so on. Though I get your point, this isn't a problem IPv6 makes appreciably much worse than the one that already exists.
It makes perfect sense precisely for the reason that a group of four decimal values ranging from zero to 255 makes for an even worse decision. It would have been logically much easier to deal with IPv4 addresses if instead of 255.255.255.240 you had something like ff:ff:ff:f0. What is the next largest prefix in dotted decimal format? It is much less obvious for many people to come up with 224, whereas it would have been simply if you just count down with hex and so that f0 becomes e0. Using your argument above, I'm not sure I'd want fe80::208:74ff:feda:625c to become 254.128::02.08:116.255:254.218.98.92. That looks kinda worse to me.
Any time you try to design a wheel by committee you run the risk of producing something that more closely resembles a square block. It may be imperfect, but it is better than the alternative which is nothing and in my view, while it might have been better, it could have been far, far worse.
A need is not a need regardless of the cost of adoption of the proposed solution. As it turns out, the need is satisfied with other means fine for the cost they are prepared to pay at this point. That's a totally baaaaaaad business estimation on the part of the IPv6 designers. Which makes sense, because engineers don't tend to foremost care about business costs. Thus, the grave "errors" in desinging the product.
Good points, I do appreciate intelligent conversation in this sea of... whatever we have here at LET. Thank you.