[HN Gopher] Dev vs. Ops (2017)
___________________________________________________________________
Dev vs. Ops (2017)
Author : Tomte
Score : 48 points
Date : 2023-06-11 13:28 UTC (1 days ago)
(HTM) web link (www.bassi.io)
(TXT) w3m dump (www.bassi.io)
| eisbaw wrote:
| https://nixos.org/
| dogleash wrote:
| The admins and distribution maintainers in this article are
| really a proxy for all stakeholders beyond a developer who's
| doing the minimum to get a feature into production.
|
| But, the requirements the tooling and workflows were built for
| didn't lend themselves to use in development, preventing
| evolution into tools that work well for more use cases.
|
| I started rebuilding and deploying .debs with custom patches for
| production 15 years ago. For some projects .rpms or .debs are the
| only way we distribute builds that go beyond individual developer
| workstations. It's an absolute luxury on projects that are
| amenable to workflow. But I've never been a distro maintainer. So
| I both feel limitations of the tool, and simultaneously don't
| feel like I have a good grasp on leveraging those those tools as
| well as I could.
| kkfx wrote:
| I suggest a different point of view: modern "way to distribute
| software" are BAD response to a problem that should not exists in
| the first place.
|
| For instance we all know "the dependency hell", but we also know
| the stockpile of wasted resources to deploy essentially an entire
| OS minus the kernel and few surrounding just to deploy a small
| app and the issue such model have with gazillion of built-in
| vulnerabilities because the small chat client dev do not have
| upgraded OpenSSL simply because for him is just marginal. We know
| the idea of "separation" and the normal failure because we need
| integration, resulting in pushing data outside the desktop or
| punching holes here and there in a Babel's alike tower of CRAP.
|
| Essentially BOTH model does not work.
|
| So? Well... In the classical systems there was no OS - userland -
| application software. Just a single application where various
| actor develop different aspects, including the end users, since
| they were "end users programming environments" and "programming"
| was just a simple and easy interaction with "the system" (the
| single fully-integrated app). Those systems have had their own
| set of issues, but they have offered MUCH MORE with much less
| hell than newer systems. Yes, much more. Yes, an old Alto offer
| TODAY much MORE than a modern system to the end user.
|
| Both "modern" systems, those with the classical "Unix approach"
| (GNU/Linux classic package management) and those with "Windows
| approach" (modern package management systems like snap and co)
| are the result of the need to sell software as a product before,
| as a service thereafter. They do not have solved the issues of
| pioneering BUT they have added much new issues.
| Metaluim wrote:
| But the model you mentioned also doesn't work, because it's
| essentially single-task, IIUC.
| kkfx wrote:
| As we humans "essentially" are... On our desktop we tend to
| do a thing at a time, at least if made well...
| dijit wrote:
| I upvoted this, because the discussion is worth having.
|
| However I couldn't be in more disagreement, even more than when I
| started reading it.
|
| Yeah, it's definitely easy to convince ourselves that getting the
| latest and greatest is important or that availability of software
| trumps all else.
|
| But do you know why I have 20year old rolling release
| installations of linux still running? Because there is quality
| control.
|
| The reason that in 2004 I could reinstall Windows XP and all my
| drivers inside 25 minutes was because I had done it _so freaking
| often_. Windows of today is not significantly better, it 's
| basically a CPU fighting pit of software that seeks to add their
| own special updaters and their own special UI subsystems and
| their own special tracking hardcoded with their own distributed
| libraries and eventually full of all kinds of disgusting nasty
| security holes.
|
| I mean, it's less bad than all that, but Linux is usually a
| single command and the whole system is upgraded, with a QA
| approved, security patched and moderately vetted version of all
| the software you have selected. With no special jails or layers
| of indirection and linked to your system in a way that is at
| least _moderately_ optimised for the intended design goal of the
| distro.
|
| We should be aware of what we trade away when we decide that
| package managers don't work; because frankly linux users used to
| lord it all over windows and OSX users that they were the only
| ones with a hard won and working package manager for the whole
| OS.
|
| For sure though: if I have to choose between running a docker
| container to run the hip and trendy version of `nc` or not having
| that software available... Then I choose not having that software
| available, because frankly speaking: those gatekeepers serve a
| purpose.
| mhitza wrote:
| > but Linux is usually a single command and the whole system is
| upgraded
|
| I'd wish this remained the case. As a Fedora workstation user
| (XFCE spin), it consists of a couple of steps, and a reboot for
| the upgrade. Now the annoying part where they started a couple
| of releases back to Windowsify the experience, with a nice
| upgrade screen that makes my computer useless until it installs
| the thousands of packages. I guesstimate (pessimistically),
| between the download time and installation time, it takes
| between 1-2 hours to upgrade the version (had to install around
| 4k packages the other day for the F38 upgrade).
|
| I'm quite sure they won't improve the upgrade process as they
| are definitely going to try with time to push the
| Silverblue/Kinoite (GIMP/KDE immutable distribution spins)
| further onto users. To speed it up for us that don't want to
| switch our flow, definitely torrents for package downloads, and
| smarter update packages would help (having the same package
| version on F37 & F38, but with a f38 naming suffix ideally
| shouldn't cause a full package reinstall).
| blueflow wrote:
| Perspective from the other side of the Linux world: I do
| reinstall my laptops my dd'ing a image with Alpine onto them.
| Upgrade takes like two minutes.
|
| Learning to get things done with only the terminal, i3 and a
| web browser was a big upfront task, but the result is that my
| setup does not have much requirements, both resources and
| dependencies. I've been using that setup for 7 years now
| without suffering from breaking changes. And when wayland is
| stable enough, i can switch to sway.
| anotherhue wrote:
| Now do it on reboot:
| https://news.ycombinator.com/item?id=35390782
| blueflow wrote:
| Booting diskless is the native way of Alpine to boot.
| System configuration comes as apkovl tarball. I used this
| kind of setup before but i disliked the boot times.
|
| Would be much faster if the final rootfs was packed into
| the cpio. But if i pack the cpio onto the disk, its not
| that different from using a regular disk image.
| anotherhue wrote:
| No need to choose, just treat the packages as what they are,
| object files to link into the huge program that is your
| operating system.
| https://search.nixos.org/packages?channel=unstable&query=net...
___________________________________________________________________
(page generated 2023-06-12 23:03 UTC)