[HN Gopher] New Distro 'BlendOS' Combines Arch Linux, Fedora Lin...
___________________________________________________________________
New Distro 'BlendOS' Combines Arch Linux, Fedora Linux and Ubuntu
Author : brnt
Score : 120 points
Date : 2023-01-30 11:00 UTC (12 hours ago)
(HTM) web link (blendos.co)
(TXT) w3m dump (blendos.co)
| VyseofArcadia wrote:
| > A seamless blend of all Linux distributions.
|
| Ah, yes, Fedora, Arch, and Ubuntu. That's all of them.
|
| Edit: In retrospect this comment is a little mean, but as someone
| who uses a distro that isn't one of the "big three", I am pretty
| tired of the assumption that everyone runs Ubuntu et al. that you
| frequently see in the blogosphere and elsewhere. Or even the
| implication, as you see here, that Ubuntu et al. are the only
| distros.
|
| Might I nominate
|
| > A seamless blend of your favorite Linux distributions.
|
| as a tagline?
|
| Big props to the creator. This is impressive work, especially for
| one so young.
| jbirer wrote:
| > In retrospect this comment is a little mean
|
| Did not really come across as mean, just a bit butthurt with a
| dash of cringe.
|
| > Or even the implication, as you see here, that Ubuntu et al.
| are the only distros.
|
| They are the only distros for the majority of people out there,
| most popular and the ones most people know. Smaller
| distributions need a novel feature to justify the work of
| implementation i.e the package manager of Nix
| notesinthefield wrote:
| Not literally but considering many, many distributions are
| derivatives of Debian/Ubuntu, RHEL or Arch, BlendOS can cast a
| pretty wide net.
| [deleted]
| jay-barronville wrote:
| From what I can tell, as a meta distribution, it technically
| supports a lot more distributions, but Arch, Ubuntu, and Fedora
| are the highlighted (and officially supported) ones.
| [deleted]
| jay-barronville wrote:
| Also, no need to be a jerk about it.
| VyseofArcadia wrote:
| You're right, it was jerky. Thanks for the callout.
| jay-barronville wrote:
| Respect!
| helf wrote:
| [flagged]
| ihateyouall123 wrote:
| [dead]
| merd94xn8t wrote:
| [flagged]
| pxc wrote:
| Perhaps 'all distros' is more aspirational? I hope so, because
| while I see less use for more conventional distros like those
| currently given, something similar could be a really nice
| escape hatch for distros with less conventional, less
| compatible bases. Combining a distro like Fedora with one like
| NixOS, GuixSD, Alpine, Void Linux, etc. could be much more
| valuable.
|
| BlendOS also looks like it could be quite nice for developers
| who want to be able to quickly build and test locally for a few
| major distros.
| uoaei wrote:
| > I am pretty tired of the assumption that everyone runs Ubuntu
| et al.
|
| It is a fact of statistics, and a fact of your personal choices
| vis a vis others' personal choices. But then I consider the
| language implying victimization, and I wonder why you react in
| that way.
| BossingAround wrote:
| > > A seamless blend of all Linux distributions.
|
| > Ah, yes, Fedora, Arch, and Ubuntu. That's all of them.
|
| I think the idea is to be able to run applications distributed
| via Pacman, DNF, and apt (which encompasses many more distros
| than the named three) rather than needlessly put every single
| distro into one. It is poorly worded, I'll give you that.
| pxc wrote:
| > I think the idea is to be able to run applications
| distributed via Pacman, DNF, and apt (which encompasses many
| more distros than the named three) rather than needlessly put
| every single distro into one. It is poorly worded, I'll give
| you that.
|
| It doesn't really work that way, though. Compatibility runs
| deeper than that. You can't generally just take a Fedora
| package and install it on openSUSE or vice-versa, even though
| you can run DNF on both.
|
| Same for any two releases of a given distro. You can only
| reliably do this kind of thing where one distro is directly
| downstream of one another, version for version, like Pop and
| Ubuntu.
|
| Proprietary software's Linux repos often obscure this, by
| shipping a big runtime for a package, bundling a ton of deps,
| so you may not notice this if you only ever add repos for
| Chrome and Discord via their vendors or whatever. (Not
| recommended, btw-- proprietary software repos for Linux
| distros are notoriously ill-behaved, often in a way that
| poses a security risk.)
| BossingAround wrote:
| It is an interesting idea, though the documentation being heavily
| focused on the mac ecosystem tells me that I'm not the target
| audience.
| pfoof wrote:
| Is Rudra the new Bellard?
| jay-barronville wrote:
| I'm very impressed that Rudra is apparently 13 years old and has
| built this. Despite the fact that I started coding around 12
| years old, I'm pretty sure I wasn't capable of building something
| like this at 13. That's really awesome. His parents should be
| proud!
| athorax wrote:
| He should be proud :)
| H4ZB7 wrote:
| I thought all distros were created by 13 year olds?
| still_grokking wrote:
| > Despite the fact that I started coding around 12 years old,
| I'm pretty sure I wasn't capable of building something like
| this at 13.
|
| With 13 you're (at least) in 6 grade. Don't underestimate what
| one can expect from a six-grader!
|
| Also we have now YouTube tutorials and Stack Overflow...
|
| Still I would not touch this thing. Someone with 13 does not
| have enough experience to manage serious software projects, no
| matter how smart the kid may be. (And given the idea here, I'm
| not even sure this kid is actually smart.)
| tombert wrote:
| I think 13 year olds can make great software, and I have no
| doubt that the person who made this is intelligent.
|
| Like any distro, I would probably not trust it in production
| until it's been around awhile (though I might play with it).
| This isn't a product of the creators age, though, just a
| product of hacker culture.
| luisivan wrote:
| Completely mind blowing
| ehutch79 wrote:
| I'm surprised they're advertising immutability on here.
|
| One of the issues many commenters on hacker news have with MacOS
| is SIP which is exactly this. "If random binaries on my system
| can't overwrite kernel modules on disk, it's oppression!"
| kitsunesoba wrote:
| On the contrary, I like having SIP turned on so long as there's
| a a way to turn it off. With as many 0days as there are
| floating around now and how sophisticated phishing and social
| engineering is becoming, I don't want to make things any easier
| for a bad actor than I have to... anything that can reduce the
| impact crater is good. Yeah I write software for a living but
| that doesn't mean I'm magically immune to this stuff, and I so
| rarely need to modify the root filesystem any more that it's
| not much of an inconvenience.
| ElijahLynn wrote:
| What is SIP?
| alex_suzuki wrote:
| System Integrity Protection - a macOS feature that basically
| makes your ,,system partition" read-only.
| pkulak wrote:
| With Linux, the word "immutable" (in the context of a file
| system) doesn't ever actually mean it can't be changed. Here's
| it explained better than I ever could:
|
| https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-repro...
| monsieurbanana wrote:
| Imagine confusing SIP for Nix
| oneplane wrote:
| Imagine confusing Nix for something a large user base
| actually wants.
|
| To clarify: SIP is a world-wide large-scale security
| improvement that people need, especially those that have no
| clue how their stuff works. Nix is a technical feat that has
| almost no reach.
| pxc wrote:
| No, you're missing something here. What people are after
| with immutable Linux isn't generally security like SIP
| provides. 'Immutable Linux' is about many of the features
| Nix provides, like atomicity of upgrades and rollbacks. But
| it still also has a packaged base, unlike macOS, and is
| generally more flexible than any tools for interacting with
| the base system.
|
| macOS uses a snapshotting filesystem by default but doesn't
| let you create labeled snapshots, or enable automatic
| snapshotting without cluttering your snapshot list with
| time-based snapshots or enabling auto-pruning.
|
| macOS doesn't have any of the features that help with
| disaster recovery, reverting upgrades, etc., that draw
| people towards immutable Linux, snapshotting filesystems,
| etc. This is true of not just NixOS and GuixSD, but also
| Fedora Silverblue, openSUSE MicroOS, and to some extent
| even non-immutable distros that run snapper integrations
| with their package managers, and so on.
|
| On the other hand, part of what people are after with
| immutable Linux is greater separation from the base system
| and applications, which macOS 10+ has always had.
|
| The post you're replying to is (rudely, dismissively)
| noting a disconnect between what people in the Linux
| community (relevant for this article!) and perhaps also on
| HN actually care for in immutable OSes and the idea that
| SIP should be agreeable to the same crowd because it is
| about 'immutability'. And it's right!
| oneplane wrote:
| tl;dr: agree, but there are some valuable semantics that
| matter more than we think.
|
| Do you truly in your deepest heart of hearts believe that
| the over 2 billion users that get SIP have any clue about
| what you are talking about? ;-) (probably also what
| you're getting at anyway)
|
| You wrote about a bunch of facts, which are true, but it
| also misses the forest for the trees in a different way.
| Even if you paid everyone to use Nix, they wouldn't be
| doing it, because it doesn't fit within their use case
| ergonomics.
|
| And then there are the technical facts, SIP isn't the
| same as immutability, it's a mandatory access control
| where root isn't getting any special treatment. I suppose
| from a end-user's perspective the 'result' feels similar:
| no matter how much sudo and su you type,
| writing/modifying isn't happening.
|
| That is what I was getting at in general: immutability
| (and reproducible builds of course! without those, what
| is the point of immutability, what would we measure it
| against?) is surprisingly little-understood for what it
| is. As you point out, you can for example use it as a
| chain of snapshots that with writes can go forward in
| time but never backwards. Or you could see it as a
| package-based construction where the packages and their
| contents are not mutable, but which package you use is.
| Or if we'd be talking about layers, we could have a
| union-esque representation of multiple immutable layers
| together forming a complete rootfs.
|
| As far as I understand, BlendOS is mainly Arch + Docker,
| but with some added WSL2-like UI sugar. That makes it
| about as immutable as Docker itself, which is to say:
| depends on how you configure it, since there are no
| mutability guarantees with docker, only intentions. You
| can use cgroups2 to make sure the namespace will never be
| able to write to an actual persistence store, but at that
| point people are re-inventing ZFS.
|
| SIP itself is best comparable to mandatory access
| control, where UID 0 doesn't get to bypass MAC. But if
| you get something that has the right entitlements, it's
| just another ACL. Imagine getting a busybox binary with
| the right entitlements: SIP would let you do anything.
| pxc wrote:
| > SIP itself is best comparable to mandatory access
| control, where UID 0 doesn't get to bypass MAC.
|
| Yes. And it's an area where desktop Linux is really
| lagging-- we don't have much in the way of very simple,
| toggleable MAC. (We just have the heavy duty stuff where
| you have to write policies per application in a complex
| DSL.)
|
| But you can see why that's not _exciting_ , and
| potentially even annoying, to hackers who want features
| and capabilities. Barriers aren't fun, even when they're
| useful and necessary.
|
| > As far as I understand, BlendOS is mainly Arch +
| Docker, but with some added WSL2-like UI sugar. That
| makes it about as immutable as Docker itself, which is to
| say: depends on how you configure it, since there are no
| mutability guarantees with docker, only intentions. You
| can use cgroups2 to make sure the namespace will never be
| able to write to an actual persistence store, but at that
| point people are re-inventing ZFS.
|
| I admit I don't understand why Distrobox uses OCI with
| Docker or Podman rather than LXC. Docker is centered on
| containers that are basically glorified, heavyweight
| processes. Docker is _for_ shipping individual
| applications, not persistent operating system
| environments.
|
| LXC containers, on the other hand, really are system
| containers-- they're for whole, persistent environments
| rather than for individual, disposable processes. And LXC
| natively supports snapshotting containers, just like you
| might do on a VM. So with the appropriate container
| technology, you don't need to reinvent (or leverage) a
| CoW filesystem on the metal like ZFS or BTRFS.
|
| You could totally have a tool like `blend` wrap `lxc
| snapshot` or whatever before and after the guest package
| manager operations to give you the ability to rollback
| even each ad-hoc action of the various guest package
| managers. This is how BTRFS snapshot integration works
| for pacman via Snapper today, for example. Other package
| managers integrate it via plugins to the same effect.
| You'd just be applying the same technique across multiple
| containerized systems here. You would get time travel, if
| not reproducibility. :)
| oneplane wrote:
| If I'm not mistaken, Sun did the same thing with Solaris
| and ZFS; rolling forwards or backwards was just a matter
| of choosing the rootfs snapshot of choice. You can even
| run multiple zones from the same base snapshot and have
| their own (ephemeral) writes on their own timelines. And
| on BSD we can do similar things with Jails.
|
| Considering all those technologies (LCX, cgv2, Jails,
| Zones, containerd etc.), you'd think we're all heading
| for the same goal and might as well combine strengths
| instead of yet another packaging/state manager method.
| Maybe once Snap, Flatpak, Nix etc. all get one or two
| generational replacements we'll get the
| state/mutability/layered approach right (at least on
| Linux) and we can all focus on MAC in a way that is less
| convoluted than LSM/AppArmor etc. But I bet we'll all
| still be in SBOM hell for years to come before that gets
| attention again.
| hackmiester wrote:
| What does this comment mean?
| rbreaves wrote:
| Really should be including Budgie DE imho. It literally blends
| the best things about any and all DEs as far as I am concerned.
| tw1984 wrote:
| by a 13yo kid
|
| pretty impressive, surely I couldn't pull this off when I was 13.
| kitsunesoba wrote:
| Yeah, if my memory isn't failing me, at that age I think I was
| mostly doing desktop customization stuff by downloading/making
| Kaleidoscope schemes and wallpapers and editing resource forks
| with ResEdit. I'd started dabbling in REALBasic and could build
| some toy apps with it, but nothing terribly complex or useful.
|
| When I see teenagers founding Linux distros and reverse
| engineering GPUs it seems a little crazy. Impressive and good,
| but it's hard to imagine being that technically capable at that
| age.
| lakomen wrote:
| [flagged]
| 28304283409234 wrote:
| Yup. Sounds like 13 to me!
| sirtomato wrote:
| What the hell!? I started at 9 or something and I still can't
| write anything useful
| pxc wrote:
| Praising children, even when it involves a nominal comparison
| to oneself 'at that age' or whatever, is about celebrating
| their successes, not actually competing with them.
| chaorace wrote:
| Technically, that's how _all_ praise is supposed to work.
| Comparing accomplishments is a short-circuit pathway to
| tearing others down.
| Vinnl wrote:
| A similar project is Vanilla OS (https://vanillaos.org/). It has
| its own `apx` package manager, which has roughly the same
| interface as apt, but also supports installing packages from
| Fedora or Arch - though it encourages using Flatpaks where
| possible, as the other packages run inside containers.
| ilc wrote:
| https://github.com/89luca89/distrobox ; Is what this is really
| built on.
|
| I'm guessing the rest is just chrome, and getting a base OS of
| some form down, so you can use distrobox.
|
| Read what the page says, then look one layer deeper. You may want
| to use distrobox in on your existing machine to try things out.
| deafpolygon wrote:
| Missed a chance to call it Hydra...
| doubled112 wrote:
| https://en.wikipedia.org/wiki/Hydra_(operating_system)
|
| https://en.wikipedia.org/wiki/Hydra_(software)
|
| https://www.hydraos.io/
|
| Already been done? Not that it changes anything, blend is a
| pretty common word.
| pxc wrote:
| Also the first CI/CD system built on/for the Nix package
| manager. A public instance powers the main binary caches for
| NixOS to this day?
|
| https://hydra.nixos.org/
|
| https://github.com/NixOS/hydra
| spicybright wrote:
| What's the use case for this?
|
| I get why it may be useful in a few situations, like you want to
| test code for a server running a certain distro, I suppose.
|
| But it's not like there's exclusive software between the three,
| or a huge difference between them besides some pre-installed
| software.
|
| The immutable filesystem seems interesting, but I'm still not
| sure what the advantage to it is. How would you install software
| on a read only system?
| dhruvdh wrote:
| There are some professional software, like AMD's ROCm that only
| work properly in a few officially supported Distro's. `amdgpu-
| install` specifically checks what distro you are on and refuses
| to proceed when it encounters unfamiliar OS releases. It's a
| headache to work around.
| dartharva wrote:
| Reducing fragmentation for Linux desktop end-users?
|
| Many developers only bother packaging their apps and software
| for one platform (e.g. only on a PPA or only on the AUR), which
| makes it hard to use on others.
| yellowapple wrote:
| The use case is that it's fucking cool :)
|
| More seriously: if you're writing software for Linux, this sort
| of thing could be a boon for packaging that software.
|
| > The immutable filesystem seems interesting, but I'm still not
| sure what the advantage to it is. How would you install
| software on a read only system?
|
| Usually it's just the root FS that's read-only; /home is
| usually still r/w, so applications would get installed there
| (or into some other FS that's r/w and not root). This approach
| ain't _terribly_ new - openSUSE 's MicroOS and Valve's SteamOS
| 3.0 are both good instances of prior art, and I'm pretty sure
| Android and ChromeOS work similarly - but it's cool to see this
| idea continue to catch on.
| 7speter wrote:
| Maybe I'm wrong, but I kind of think that if Linux wants
| widespread adaption, there gas to be a one stop solution for
| users, instead of a distro thats ideal for ML, a distro ideal
| for video editing (looking at you davinci resolve), a distro
| for audio editing, a distro for streaming and a distro for
| gaming (surprisingly all distros). Maybe that involves a
| kernel implementation that can handle all of that (seemingly
| easier said than done) or a convergent distro, or flatpaks,
| or scripts that seeks updates im the source code...
| cassianoleal wrote:
| > The immutable filesystem seems interesting, but I'm still not
| sure what the advantage to it is. How would you install
| software on a read only system?
|
| I don't know about this particular system, but generally you
| install software on overlay filesystems.
|
| macOS has an immutable (by default) root filesystem. The Steam
| Deck does that as well.
| madduci wrote:
| I think it suits very well the Kiosk use case with UI or
| Digital Signage systems where updates are downloaded at each
| boot.
| cassianoleal wrote:
| It does. It also suits very well the use case of the
| personal computer and other personal devices, as
| exemplified with macOS and the Steam Deck.
|
| It helps keep the core system free of malware.
|
| I'm not sure about macOS but my understanding is that the
| Steam Deck does upgrades in a blue-green fashion so if
| something goes wrong, the previous, known good system is
| still available.
| kitsunesoba wrote:
| Immutable base image also reduces chances of software
| that's not malware unintentionally screwing things up or
| putting files in places it has no business putting them
| (as Adobe loves to do).
|
| macOS obviously has its desktop environment as part of
| the image, which makes it difficult to accidentally
| destroy your desktop environment, is that true of SteamOS
| too? Seems like it'd be smart if the immutable image at
| least included a minimal fallback like IceWM or something
| that it spins up if say the package manager loses its
| marbles while resolving dependencies or something and
| eats the stock KDE install.
| francis-io wrote:
| For me, the value of Ubuntu is the community support around it.
| I'd love this project to take off and become mainstream.
| alganet wrote:
| Made me remember of https://bedrocklinux.org/
| nyanpasu64 wrote:
| I tried Bedrock on a throwaway machine, but gave up on it
| because Linux wouldn't sleep properly when the FUSE server
| process got suspended before the applications with ongoing
| filesystem operations could complete to a suspendable state:
| https://www.reddit.com/r/bedrocklinux/comments/h8sgkk/suspen...
| ParadigmComplex wrote:
| I've looked into this further since the link you've provided.
| I have medium/long term ideas to work around this, but
| nothing in the short term:
|
| - Ultimately this seems to trace back to a bug in the Linux
| kernel. Sadly, I don't see any reason to believe it's going
| to be resolved in the kernel any time soon.
|
| - A potential medium-term fix is for Bedrock to offer the
| corresponding functionality via a kernel module, and to fall
| back to a FUSE implementation if the module is unavailable
| (e.g. if you reboot into a kernel that breaks compatibility
| with the module). The proper way to do this would be via
| dkms, but is thus blocked on cross-distro dkms functionality.
| This is a realistic route, but given limited project
| resources it's likely quite a ways away.
|
| - The long-term fix is to upstream Bedrock's required
| functionality into the Linux kernel directly. The main issue
| here is that we don't know _exactly_ what functionality
| Bedrock actually needs here; it 's often changed quite a bit
| from release to release. Keeping it out of the kernel tree -
| and using dkms/FUSE - offers needed flexibility in Bedrock
| Linux's pre-1.0 period.
| WorldPeas wrote:
| I really wish someone would make a blended OS of nixos and
| ubuntu. Declarative when you need it, but dirty when you need it
| too
| tadfisher wrote:
| nix-env (or the modern "nix profile") is how you get dirty with
| Nix.
| tbenst wrote:
| Installing home-manager on Ubuntu is practically a blend of
| NixOS and Ubuntu.
| koiueo wrote:
| systemd-nspawn is available in NixOS
| somat wrote:
| The primary distinguishing feature between linux distros is the
| package manager, the secondary distinguishing feature is how the
| network is configured, that is going away as network manager
| becomes more common. Anyway forget the network config, my point
| is that having more than one package manager does no one any
| favors, so they are going to have to pick one.
| forgotpwd16 wrote:
| Goal seems similar to Bedrock but implementation* differs. This
| one seems more desktop oriented, more stable (uses a a
| conventional approach of containerization of other distros), but
| also less flexible (Bedrock allows mix-and-matching even system
| packages).
|
| *It's basically Arch + distrobox which handles all the low-level
| work.
| mdwalters wrote:
| this is amazing! can't wait to try it out!
| nashashmi wrote:
| What happens when the same app is installed from both RPM and
| APT? Does it correctly say that it is already installed? Or does
| it overwrite and cause conflicts and issues down the line?
| still_grokking wrote:
| Updating all the containers with security fixes is for sure
| also "funny"...
| forgotpwd16 wrote:
| Installation is in distinct containers. So _probably no_ and
| _no_.
| pxc wrote:
| How does the approach of BlendOS compare to that of Bedrock
| Linux?1 (Site won't load for me atm, sorry.)
|
| What's the process for adding/porting another distro?
|
| --
|
| 1: https://bedrocklinux.org/
| ParadigmComplex wrote:
| I can speak authoritatively for Bedrock Linux, although blendOS
| is new to me. From what I can tell reading about blendOS, key
| differences seem to be:
|
| - blendOS appears to use a common host-container relationship,
| with automation to make things in containers transparently
| accessible in the host. Bedrock does not currently privilege a
| section of the system like this; everything is "equal." The
| Bedrock philosophy here is that privileging a section like this
| is limiting; it essentially defines a section of the system
| which must come from one distro rather than have the same
| flexibility as other sections of being able to come from any
| (supported) distro. The downside to Bedrock's flexibility is
| that has a higher ceiling on complexity.
|
| - blendOS's documentation refers to getting "apps" from other
| distributions, where as Bedrock's aim is as much as it can do.
| My guess is Bedrock lets you integrate more types of things
| across distro boundaries. Bootloader, kernel, init, desktop
| environments, fonts, man pages, shell completion, etc. Like the
| previous bullet point, this can be a mixed bag and result in a
| higher ceiling on complexity.
|
| - I do _not_ see blendOS mentioning the ability to run systemd
| services from different distros. However, it seems to be built
| on distrobox, which does offer such a thing by leveraging
| systemd 's ability to manage services in host-container
| relationships, and so my guess is blendOS can or easily
| could/will allow for such functionality. Bedrock does not
| currently offer this. Bedrock explicitly is not containers, and
| so it does not support multiple simultaneous init systems like
| this. Bedrock has an alternative on the roadmap, but it's a
| very long ways away.
|
| I think a closer alternative to blendOS would be Vanilla OS
| [0]. Like blendOS, it has an immutable "base", although it is
| Ubuntu-based rather than Arch-based.
|
| [0] https://vanillaos.org/
| isp wrote:
| I was curious about the same, so had a look round.
|
| The main innovation in blendOS is the "blend" package manager:
| https://github.com/blend-os/blend
|
| Under the hood, this uses "distrobox" to create containers for
| supported distributions: https://github.com/89luca89/distrobox
|
| Supported distributions are defined in "blend" here:
| https://github.com/blend-os/blend/blob/4e4bdd33d2de374cb01e4...
|
| Additionally, there are wrappers for commands like "apt", which
| in turn call "blend", which in turn calls "distrobox":
| https://github.com/blend-os/blend/blob/main/pkgmanagers/apt
|
| In contrast, Bedrock Linux has a quite different
| implementation, with the most widely used strategy being based
| on "strata" and a FUSE filesystem "crossfs". See "How does
| Bedrock Linux Work?" on https://bedrocklinux.org/faq.html#how-
| work
| pxc wrote:
| Right, Bedrock really plugs the various distros into each
| other in a deep way, and offers ways to do that for many
| components of the stack (init system, display server, network
| management stack, etc.)
|
| It sounds like the blendOS approach is a bit coarser but
| probably also safer and less likely to be surprising to non-
| expert users.
|
| `blend` seems like it could potentially be adapted and
| usefully added to almost any distro as a feature that users
| could enable/install if they want, whereas Bedrock Linux
| might be a useful upstream for more custom distros where
| things are more tightly integrated.
|
| Anyway it's cool to see a distro developer writing tools like
| this because there's a lot to learn from Linux package
| managers, but there's also a lot of space between the state
| of the art and what's in common use. Writing tools like this
| might be the kind of practice one needs for putting together
| something next-gen which incorporates the state of the art
| but suits mainstream tasted and benefits from hindsight.
| MuffinFlavored wrote:
| Honest question, why does anybody typically need anything other
| than Debian? Imagine if we took all of the resources used in the
| different flavors of BSD/Linux distributions and paired them to
| more common goals instead of doing the same thing (package
| management, init) slightly different ways. Seems like a huge
| amount of waste on a massive scale.
|
| edit: Debian or RHEL/CentOS due to the support contracts
| jacobr1 wrote:
| While I use debian for all my personal stuff (and years ago
| before that - slackware ) most my employers have used RHEL or
| CentOS due to the support contract (or potential to easy
| transition to RHEL with support in the centos case). This
| satisfied both compliance and contractual needs.
| htag wrote:
| I think you might be underestimating how different package
| management is between Debian, Arch, and Fedora. This also
| ignores the many other differences.
|
| Debian stable will have packages that feel very out of date.
| Debian unstable (sid) makes no guarantees that an update won't
| introduce breaking changes.
|
| Fedora Linux has six month major releases, so the packages feel
| fresher than Debian stable, but are much more stable than
| Debian unstable. The six month major release vs a rolling
| release means twice a year you'll have to watch an update
| carefully.
|
| The barrier of entry for releasing an AUR package is
| incompatible with my standards of system security, so I refuse
| to use them. The official repositories feel a little bare in
| comparison to Fedora and Debian because they have an
| expectation that AUR will fill in any gaps.
| arwineap wrote:
| Personally I don't like debian because of how hard it is to
| crack to make changes
|
| Someone mentioned debian-testing, and I agree it gets updates
| more quickly which is great, and solves for half the problem
|
| However, when you want to make a change to one of those
| packages, it's probably going to take me a couple days of
| playing around with the dev tools to repackage it and install
|
| Archlinux's abstractions around this are really good. You
| download the ABS store, cd into your package and view the
| pkgbuild file. Once you have abs downloaded, you can edit it
| and install it like any other aur package
|
| Yes, I've built my own debs, yes I've built my own rpms; abs
| and aur are miles ahead in this regard
| rgoulter wrote:
| Different use cases / priorities, & different acceptance of
| trade-offs.
|
| Consider, say:
|
| Arch Linux is bleeding edge, but requires a lot of knowledge /
| elbow grease to get working.
|
| NixOS allows for declaring the whole operating system from a
| consistent entry point; but has a steep learning curve.
| still_grokking wrote:
| Arch Linux is most of the time not more "bleeding edge" than
| Debian Testing.
|
| But when updates didn't roll into Debian Testing timely this
| has usually real reasons. Most of the time you don't want
| those updates on any productive system as there are severe
| issues. (Except when some more exotic software package
| doesn't have a proper maintainer team behind; than updates
| may be delayed even infinitely; but in this cases the quality
| of the maybe existing AUR packages also often isn't good;
| exotic stuff is just less supported everywhere.)
| bityard wrote:
| Why does anyone need to buy any car that isn't a Toyota
| Corolla?
| MuffinFlavored wrote:
| What has a higher net-negative impact:
|
| me having a personal preference on a car
|
| or
|
| a bunch of projects existing, working towards wasteful goals
| instead of ceasing to exist, uniting, and working towards
| more meaningful goals
| RussianCow wrote:
| How are these not exactly the same thing? If Toyota only
| made one car, it would be better and cheaper, so why don't
| they consolidate their efforts instead of "working towards
| wasteful goals"?
| MuffinFlavored wrote:
| Me choosing to spend my extra resources (money) on
| something that I prefer above the base (something other
| than a Toyota Corolla) only hurts me
|
| 100,000 developers across the world working on 1,000
| different Linux distributions each with slightly
| different takes on init + package managers (managing
| bugs/releases/documentation) hurts the general population
| because if they used their time (resources) on something
| better, we'd all (potentially) benefit
| still_grokking wrote:
| This is actually a good question given the fact that our
| resources are limited.
| bradwood wrote:
| S/Debian/Arch/ :)
|
| But yeah, in principle I agree.
|
| Sounds like bloatware.
| 3836293648 wrote:
| s/Arch|Debian/NixOS
|
| The mutable package management model is broken by design.
| What we need is a better interface for something that
| actually works
| ilc wrote:
| And you all have proven the point of why we need multiple
| distros.
|
| Different goals,and different audiences.
| EGreg wrote:
| Does this mean I can run yum and apt, like I always wanted? Yay!
| flanked-evergl wrote:
| Seems like it uses https://github.com/89luca89/distrobox - but
| you can just use this directly from most Linux distros anyway.
| rvz wrote:
| > blendOS is an immutable operating system. This means your
| filesystem is read-only, thus resulting in stable experience.
|
| The only feature that makes sense in 2023.
|
| Having a root user with full system r/w permissions had always
| been a bad idea since the days of UNIX, which is not designed for
| security uses. Now in 2023 at least one distro makes the change
| to a fully read-only file system, by default.
|
| Perhaps smashing up the popular distros that have caused this
| Linux desktop fragmentation for years into an all-in-one fully
| compatible single distro is the only hope of a Linux desktop
| standard coming out of this rather than the confusing 'choice'
| contraption that no-one can define Linux Desktop support for.
| still_grokking wrote:
| Now you have a non-root user who can do whatever he wants in a
| gazillion of containers.
|
| Seems like a clear security win. /s
| ciupicri wrote:
| We had Live CDs since around 2003 if not earlier.
|
| Today we also have Fedora IoT [1] & Silverblue [2].
|
| [1]: https://docs.fedoraproject.org/en-US/iot/
|
| [2]: https://silverblue.fedoraproject.org/about
| hulitu wrote:
| what's wrong with
|
| mount -o ro,remount /
|
| ?
| jraph wrote:
| A lot of stuff, sometimes subtle, may start breaking if you
| do this on a distribution that's not designed for it.
|
| You might have unattended upgrades that fail for instance. Or
| journal logs failing to be saved.
|
| It can work, but it needs work.
| felixg3 wrote:
| Before people come to early conclusions, remember that this is
| done by Rudra Saraswat, a known figure in the FOSS scene. I guess
| it's more than just another distro doomed to die quickly.
| pxc wrote:
| Is that the kid who maintains Unity 7 these days? My (very
| distant) impression is that he gets taken seriously by
| collaborators because he does serious work, so he's not limited
| to gimmicks. I don't think he makes stuff just to put his name
| on it, but because he really wants to do something.
|
| The creator of one of my favorite distros from my own childhood
| also started as a Linux distro developer when he was in high
| school. By the time he went to college he wrote his own
| (excellent) package manager from scratch for the distro that
| grew out of those same efforts. blendOS might grow into
| something that surprises all of us some day. :)
| pkulak wrote:
| Anyone know how the immutability is handled? I've seen OSTree,
| btrfs snapshots, and partition swapping in the wild; very
| interested to know the take here.
| isp wrote:
| I was curious about this too, so went digging.
|
| The immutability is handled by "nearly", created for blendOS:
| https://github.com/blend-os/nearly
|
| (In turn, "nearly" is called by the "blend" package manager,
| e.g., "sudo nearly enter rw", "sudo nearly enter ro" -
| https://github.com/blend-os/blend/blob/main/blend)
|
| At the heart of "nearly" is toggling inode flag
| "FS_IMMUTABLE_FL" (equivalent to "chattr +i" / "chattr -i") on
| each file within specified directories (currently "/usr"):
| https://github.com/blend-os/nearly/blob/3bb6f662818545cba1eb...
___________________________________________________________________
(page generated 2023-01-30 23:02 UTC)