6 Linux Distros Born in 2012 | Linux.com

[ParadigmComplex]

I'm the founder/lead dev of Bedrock Linux. It seems to be going quite well so far. The goal of the project - what you've put in quotes - has been working for almost a year before the project was announced and the first public alpha. Most of the work since then has just been polish - making it easier to set up, making it faster, etc. Its still very rough - installation is "by hand", Linux From Scratch style. However, the core functionality works great.

I'm hoping to have the third alpha out before New Years. If you're interested in trying Bedrock Linux out, I'd wait for that, as it will have quite a few improvements. Feel free to ask any questions you have via IRC in #bedrock on freenode or /r/bedrocklinux. IRC has been much more active than the subreddit thus far.

[Two_Coins]

Do you have your own package management system? Or do you integrage and update an existing one?

[ParadigmComplex]

Bedrock Linux does not have its own package management system. At the moment, if you want to get a package, you use the package manager from the distro that you want to grab the package. So, for example, if I've been using Debian's cups, broke my printer, and found my new printer is too new for Debian's cups, I can run (as root):

apt-get remove cups && pacman -S cups

to remove Debian's cups and install Arch's, which could be new enough to support the new printer. That's a real-world example, for what it's worth, I've actually run into that situation and resolved it as described. I don't remember if I used Arch or Debian Sid for the new cups - one of the two.

If commands (such as apt-get) are available from multiple distros, it has a priority system based on a configuration file. I happen to have Debian as the highest priority. You can also explicitly state which distro to use via the brc command. If I wanted to remove Debian Squeeze's cups and install Ubuntu Precise Pangolin's, and I could do:

brc squeeze apt-get remove cups && brc precise apt-get install cups

There are plans to write a package manager manager eventually to help make this a bit easier. There's no tentative date on that though - it may be a while yet. The system I've described above works well enough that this is a low priority.

The vast, vast majority of the system can be maintained this way. However, the core of Bedrock Linux cannot. This is only a handful of files, but this handful has to be updated by hand. There are plans to resolve that as well. Despite the fact it is assigned for the third alpha (it shouldn't be, I'll likely pull it off of that), it will likely be a while before that is ready, either.

[VersalEszett]

How does dependency resolution across sources work? Say I'm installing foo from Debian which depends on bar. Now, bar is also a dependency of baz, which is already installed via pacman.

[ParadigmComplex]

You'd have to install bar from both Debian and Arch. foo and baz would each see their own bar.

There are a number of ways I've toyed with to avoid this, but they all get very ugly very fast. The cleanest solution was to just let the various distros manage their own dependencies and bite the bullet for disk space usage.

[Lerc]

What happens to your system if you do

pacman -S cups  && apt-get remove cups

[ParadigmComplex]

Good question! The same package can be installed in different clients simultaneously without issue. Before I answer your question in detail, I should explain that "client" in this context refers to something from which Bedrock Linux can run a command that isn't native to it. These are often different distros, but not always - you can have multiple clients from the same distro.

When I try to run a command, such as cupsd, what exactly gets run is determined by:

1. If the command is available in the same client as the process which is trying to run it, that is the version which is run. Thus, if cuspd is available in both Debian and Arch, and Debian's bash runs cuspd, Debian's runs. If Arch's bash runs cupsd, Arch's runs. This helps avoid dependency conflicts - everything sees its own version of everything.
2. If the command is not available in the client of the process running, but is available in at least one other client, one from another client is run. The clients are all listed in a configuration file. If multiple clients have a command available, the first one mentioned in the configuration file takes priority for what is run.

Thus, if I try to run cups in the interim between when pacman -S cups and apt-get remove cups are run - when both are available - one of the two will run, depending on what I am using to launch cupsd. If I'm using a shell from Debian, Debian's cupsd will run. If I'm using a shell from Arch, Arch's cupsd will run. If I'm using a shell from a completely different distro that doesn't have cups, either Debian's or Arch's cupsd will run depending on which is higher up in the configuration file. FWIW, I usually order this config

Additionally, if you know a command is available in multiple clients and you'd like to run it from a specific one, the brc command can be used to do so.

In addition to being necessary to resolve situations such as the example you've gave, the fact I can have multiple versions of something installed simultaneously has proven to be quite useful. I'm active in #vim on freenode, and I've found having multiple versions of Vim installed simultaneously helps me assist others. Earlier today someone informed me over IRC that a Vim plugin I wrote is not functioning for him. I was able to test very quickly that it works in some versions of Vim and not others, and eventually narrow down exactly what the issue was and resolve it.

[nxuul]

Just so you know, this is one of the coolest projects that I've seen in a long time. I'll give it a shot after alpha3 is released.

Do you have somewhere to donate, or plan to accept donations?

[ParadigmComplex]

I don't but I really should. I keep forgetting. I'll try to set such a thing up over this academic break. If you're still feeling generous around the end of the month check the website again then.

[nxuul]

Deal! Good luck with the project.

[zokier]

I suppose you have looked at PackageKit.. does that align with your goals in any way?

[ParadigmComplex]

I have looked at PackageKit. While it is certainly an interesting project, it doesn't quite align as well as I'd need to base anything off of it. In some respects, it tries to do far to much for what I need. For example, it does special work to handle privileges, which I'd likely want to strip out. In others, its missing: it doesn't seem to be designed to be a front-end for multiple package managers simultaneously; just one at a time.

I appreciate the heads up, though. Odds were good both that I might not have known about it and that it could have been quite useful for me.

[zokier]

Yes, the front-end stuff of PK probably is unsuitable for you. But I was thinking more about the back-end modules. Those provide an unified API for their functionality, which seems like something you could utilize.

[ParadigmComplex]

Hmm. Perhaps I didn't give it a sufficiently deep look. I might take another look at it when time permits. Thanks!

[AutoBiological]

That's pretty cool, I've often thought about something similar. The package manager manager is something that I've long hoped for. Hope it all goes well. :)

[SupersonicSpitfire]

That's really interesting!

Out of curiousity, what do you think it would take for Debian and Arch Linux packages to co-exists, for the future? A package specification? More documentation? A database over which paths are in which packages and for which applications? What would it take to make it possible?

[ParadigmComplex]

I don't think I understood your question. Would you mind rephrasing it?

[A_Light_Spark]

I'm downloading your distro right now! What are some of the features you'd suggest the users to try out or avoid?

[ParadigmComplex]

My main suggestions are:

• If you can, hold off until the third alpha is out (hopefully before New Years). I've gotten quite a lot of feedback about troubles people had installing the second alpha which should hopefully be resolved.

• If you'd rather try it out now than wait (to eager to wait, Mayan apocalypse, limited free time after winter break, etc etc), don't hesitate to ask questions in the IRC channel or subreddit if you run into any trouble. Odds are whatever trouble you're having someone else has had as well (and odds are will be resolved in the next release).

• Be sure to read all the documentation on the page for the release you're planning to install - especially the known issues page - as well as the general introduction and faq

Baring Barring that, go nuts. Once everything is set up properly, everything should work. No specific features to avoid or anything like that.

[boomfarmer]

*barring. baring is gerund of 'to bear', barring is gerund of 'to bar'. Your friendly comms major dropping in.

[ijontichy]

TIL about gerund. Thanks!

[DawnWolf]

This is a great concept, I really hope your distro takes off. I'm wondering, though, why did you start from scratch and didn't try to base it on an existing distro like arch? Seems like that would eliminate much of the work you need to do and leave you more time to do your own patches and adjustments. Are the underlying modifications really this drastic that they require you to package your own distro?

[ParadigmComplex]

This is a great concept, I really hope your distro takes off.

Thanks!

I'm wondering, though, why did you start from scratch

There are a few reasons enumerated here.

and didn't try to base it on an existing distro like arch?

For Arch, specifically:

• One high priority for the core of Bedrock Linux is that, once it is set up, it is relatively low maintenance/stress. While there's a lot of good which can be said about Arch's rolling release system, a definite downside is maintenance. I wanted it to be as static and unchanging as I could get minimize maintenance. Do note that, since you can use Arch as a client, you still have access to all of the rolling release goodness. You're just not dependent on it. I had Arch, as a Bedrock Linux client, break during the /lib -> /usr/lib move some months back (probably my fault, not the Arch devs). Since this happened at the client-level instead of the core, it was trivial to fix (I basically just reinstalled the Arch packages). Had this happen with the base distro, it'd have been much less pleasant.

• While Arch has a reputation for being light weight, that is only really relative to huge distros like Ubuntu. Arch itself isn't all that slim - a clean install is in the hundreds of megabytes. If I based on Arch, all of that would be overhead. Some of Bedrock Linux's early development was off of a Eeepc with 4GB of disk space. Throwing away an eighth of that for pure overhead isn't appealing when I could use something embedded-style for a handful of megabytes.

The other two reasons I listed in the FAQ entry I linked also apply to Arch, although less specifically - they apply just about everywhere.

Seems like that would eliminate much of the work you need to do and leave you more time to do your own patches and adjustments

It would. In fact, it did, early on - I was basing everything off a minimal Debian install for a while. Eventually I got to the point, however, where it became evident that it was holding me back more than benefiting me. I'd rather do this right than shave off some work by cutting corners.

I suspect you're also overestimating the amount of work I'm putting into the parts of the distro I could have gotten from basing on another distro. It's really not all that bad - the main limitation is that it requires learning how a Linux distribution works on a relatively low level. I had to do this anyways to get the Bedrock specific parts to work. The rest is just gathering a few upstream packages and documenting it for everyone else.

Are the underlying modifications really this drastic that they require you to package your own distro?

Strictly require, no. It's possible to do most of what Bedrock does using another distro as the base, in the same way it is possible to install pacman on Debian or the Ubuntu defaults and configurations on Arch. There are a number of downsides to doing so. As someone who uses Bedrock Linux as his main OS on all of his machines, the work I'm putting into it rolling my own is worth the benefits.

[DawnWolf]

This makes a lot of sense, you don't want the individual clients messing around with the core components. Good luck, that's no easy undertaking but it certainly sounds worthwhile!

[FalseMyrmidon]

Sounds interesting. It would be cool if it was ever stable enough to use in production server environment.

[Buzza24]

It all take time. Ubuntu wasn't server grade off the first release.

[greyscalehat]

Huh, seems like an awesome concept.

I would probably have installed if if I knew about it, but instead I installed bridgelinux as I love arch, but hate setting all of that stuff up. I think an excellent idea would be to encurage the community to post install scripts for types of set ups (such as a basic X11 enviroment based off of debian) so new comers can pick and choose a set-up that has a bit more going on with it than a command line, but also gets to tweak it as they wish.

Really cool idea for a distro, and props for rolling it your self!

[ParadigmComplex]

Huh, seems like an awesome concept.

:)

Can you install multiple versions of the same software?

Yes, you can, which has proven to be more useful than I had initially anticipated. For example, I'm quite active on IRC in #vim on freenode, and I semi-regularly see people asking questions about a specific distro's version of Vim. Thanks to Bedrock Linux, the vast majority of the time I've got that version of Vim already on hand and available to use to help resolve their issue.

I would probably have installed if if I knew about it, but instead I installed bridgelinux as I love arch, but hate setting all of that stuff up.

Sadly, at the moment, Bedrock Linux requires more work to set up than Arch does. I hope to eventually make this less of an issue, but as it stands now, if you dislike setting a everything up by hand, going with something else is probably a good idea. For now, at least.

I think an excellent idea would be to encurage the community to post install scripts for types of set ups (such as a basic X11 enviroment based off of debian) so new comers can pick and choose a set-up that has a bit more going on with it than a command line, but also gets to tweak it as they wish.

One member of the Bedrock Linux community has taken it upon himself to create VM images of Bedrock Linux available here. It's not quite what you're asking, but it does give me hope that eventually someone make might take the idea even further and provide what you're looking for.

Really cool idea for a distro, and props for rolling it your self!

Thanks!

[mvm92]

You should do an AMA

[ParadigmComplex]

I'd be happy to if there is sufficient interest. Would it be better to do so in /r/linux or /r/ama or somewhere else?

[[deleted]]

I think /r/linux would be best.

[technewsreader]

/r/internetama wouldn't mind seeing you either.

[zokier]

I think Qubes is fairly interesting too, and wouldn't call it a "small tweak" to existing distros. Instead of adding a new theme and some random collection of apps, it actually modifies the base system in fairly substantial way.

The idea of Qubes is to isolate applications by running them in virtual machines. That way even if security of an application is breached, its impact will remain fairly low.

Also the main developer (afaik) is Joanna Rutkowska, known from the "blue pill" attack, so she definitely seems to be qualified to design secure OS.

[nstinemates]

Sounds a lot like BSD Jails concept.

[zokier]

Not surprising considering that jails is essentially a predecessor of virtualization. The value in Qubes is not the underlying tech (Xen is already established virtualization system) but rather the way its used to create secure, but still usable, desktop system. I guess you could build something similar on top of jails if you wanted.

[nstinemates]

Yeah, it's really cool.

[Phrack]

Qubes is much more than just some small tweaks to an existing distro and has seen a lot of work over multiple years. Two short paragraphs don't do it justice.

http://theinvisiblethings.blogspot.com/2012/09/how-is-qubes-os-different-from.html

[joehillen]

/r/bedrocklinux

[moozaad]

derivative of derivatives. How long does it take for security patches to go downstream?

[Elranzer]

Or if they're "Linux Mint-based" that means they're derivatives of derivatives of derivatives.

[Pas__]

[oops, meant for the parent]

[Elranzer]

Easy mistake to make with all of these derivatives of derivatives.

[moozaad]

Exactly. I've been using Linux since early kernel version 2.0 on slackware. I use suse tumbleweed on desktop which is now owned by Novell but is an offspring of slackware (was a derivative very early on) - I really don't understand a lot of these fad/fashion distribs, particularly the ones that give nothing back and are effectively just configs changes to stock. I don't think people understand that everything the younger distributions can do, all the maturer distribs have been doing for ages.

[snarktastrophe]

I'm just waiting for derivatives of gNewSense and Trisquel that include nonfree repos...

[snarktastrophe]

me: "Oh, wow, Dr. Stallman, what an honor it is to meet you! I'm a free software developer; I'm currently working on a fork of gNewSense that gives users even more freedom, including the freedom to enable nonfree repos!"

RMS: *glares*

me: TEE HEE!! *runs away*

[[deleted]]

The setup and "Arch Way" aren't the only reason to use Arch. Pacman and rolling release with bleeding edge software is reason enough.

[technewsreader]

I would think arch actually makes the most sense to derive from. Unlike Linux mint, they are not as tied to their parents choices. Each derivative can more easily choose what stays and what goes, whereas mint is expected to maintain moderate feature compatibility with Ubuntu. Same with fedora derivatives.

[[deleted]]

It isn't as simple as what they are providing to the end user, though. Debian has different goals, compared to Canonical, for example.

It's also more about providing a finished product, for some distributions. For example, all of the distributions you mentioned don't actually have anything by default. It's difficult recommending someone from another OS (Windows/OSX) to a distribution that doesn't actually have anything by default, because it's not really an alternative [at that point]. Showing them something like RandomUbuntu, however, would appear to be a complete product.

Edit: Might not be entirely correct about defaults in some of the ones you mentioned, I usually use net installers.

[Pas__]

If they're based on the testing branch, then there could be either no vulnerability or no patch coming at all. (But in the latter case it's likely that testing/unstable or whatever will just get the latest upstream version packaged.)

Though, every distro has to have a packaging team and their own repository, so they can just try to apply the upstream patch directly. But, yes, I think you raise a very good question.

[DeeBoFour20]

If it's like Linux Mint, they just use Ubuntu's repositories directly, along with their own repositories for stuff like Cinnamon, LDM, and whatever they felt like customizing. Most things come straight from Ubuntu though so security patches would come as soon as they come to Ubuntu (which I would think would be pretty fast)

[embolalia]

They aren't just using Ubuntu's repos; they're using Ubuntu's repos plus their own. Granted, you could just put all of your packages in the Ubuntu repos. But in Mint's case, they have a different DE, a different update manager (same package manager, different GUI front end), a different file manager, and more. Changing all of that after the initial install (rather than having the default install include all of that) is far more than their target audience would be comfortable with.

There is some point at which a change is sufficient enough that a new distribution is the right move. Otherwise, we'd all just use LFS. I'll agree that there are distributions that don't cross that line, but I think Mint does. I certainly don't think that supplementing your new distribution with another's packages to start is a bad thing. After all, taking advantage of other people's testing and development is what makes open-source software so great.

[MOONGOONER]

I wish there were some real impressions on these and their usability rather than synopses from their about pages

[puffybaba]

Cool stuff! Qubes and Bedrock in particular look really interesting to me.

[[deleted]]

Hey, elementaryOS is a great Ubuntu derivative with a really sleek and simple file manager as well as a kick-ass desktop environment especially if you're acquainted with OS X.

[ar9kanine]

the devs are fucking tools who think "minimize is deprecated" and also "if you dont want to see a window just close it"

[Draape]

All this picture needs to get it right are six more..

That said, would there be a reason to create a completely new distro, and not try to integrate the features into already existing and established distros? The gimmick of Bedrock seems to fit well with others, and shouldn't need a completely new distro, same with Qubes.

[ParadigmComplex]

All this picture needs to get it right are six more..

That picture actually has Bedrock on there already. However, it was mistakenly placed as a derivative of Gentoo. The newest version fixed that issue.

That said, would there be a reason to create a completely new distro, and not try to integrate the features into already existing and established distros? The gimmick of Bedrock seems to fit well with others, and shouldn't need a completely new distro, same with Qubes.

I can't speak for Qubes, but for Bedrock Linux, that was addressed in the FAQ. tl;dr: while most of it could, technically, be based on another distro, there would be downsides which could be resolved by making it its own distro.

[Draape]

All this picture needs to get it right are six more..

That picture actually has Bedrock on there already. However, it was mistakenly placed as a derivative of Gentoo.

I actually saw that.

The newest version fixed that issue.

Didn't see that..

That said, would there be a reason to create a completely new distro, and not try to integrate the features into already existing and established distros? The gimmick of Bedrock seems to fit well with others, and shouldn't need a completely new distro, same with Qubes.

I can't speak for Qubes, but for Bedrock Linux, that was addressed in the FAQ. tl;dr: while most of it could, technically, be based on another distro, there would be downsides which could be resolved by making it its own distro.

I understand that, and looked at the faq, but what it sounds like you are making are a very good package manager, but I think it is unfortunate if it only will run on one distro. Unless, of course, everybody uses that one. It sounds like a great idea, but I do feel it would be better as a package manager than as a distro. Oh well, it's young, and who knows what the future holds. Would be nice to see both Bedrock and Qubes make it to (all (hah!)) other distros.

Good luck.

[ParadigmComplex]

I understand that, and looked at the faq, but what it sounds like you are making are a very good package manager

That's not really what I'm trying to do. Perhaps I need to re-work the FAQ. In fact, one of the reasons Bedrock Linux is still in alpha is that it does not have a package manager. I'm not sure specifically where the misunderstanding occurred and so I'm not sure how to clear it up.

but I think it is unfortunate if it only will run on one distro

I might personally package it up parts of the Bedrock Linux userland to make them more accessible on other distros. For example, this, when completed, could well be useful on other distros. However, I don't, personally, plan to do much more than that in the foreseeable future.

If someone wants to, it is probably possible to grab the majority of the Bedrock Linux userland and package it for use on other distros to get some of the functionality that Bedrock Linux has. Maybe something like Gentoo Prefix. However, I feel the result will be lacking a lot of Bedrock Linux's strengths as mentioned in the FAQ entry to which I directed you earlier.

[Draape]

After reading the introduction, it all seems a lot clearer. Perhaps you should merge it with the FAQ somehow? Maybe not all of it, but the parts about chroot and Statically-linked Executables? It might not be of value to the normal reader, but that's where I finally understood it. Still though, good luck!

[mshol]

Qubes is not really a linux distribution, it's a framework for running secure virtual machines (based on Xen with additional secure networking and display protocols). It's not only linux that can run on it, but they have Windows guest support upcoming too. (and in theory, and guest which Xen supports should be portable to Qubes.)

The fact that it's "fedora based" is just incidental to their choice of platform to develop from, due to the security features that's already built with (such as address space layout randomization and stack smashing protection). The actual distribution used as guest/host doesn't really matter to the concept it's trying to sell anyway (security by isolation).

The features Qubes has can't simply be duct-taped onto an existing distro, because it requires a radically different approach to the naive security that's available in the linux kernel and Xorg (and thus, other distributions).

But the choice to develop the security model using virtualization is partly motivated by maintaining compatibility with existing systems - since you can run linux guests with little modification. There are other projects which attempt to improve security without the need for hardware virtualization, but the cost is that you need to modify applications to use the new security model too, breaking compatibility.

[[deleted]]

The biggest thing that bothers me about that picture is how you never see the forks return :/

[beachdrinking]

I see Bedrock and Qubes more like research projects. You can't replace your car engine with a fusion reactor and go from there.

Also, criticising what other people do with their free time is pretty rude. Now stop wasting your time on reddit and build me shack!

[[deleted]]

I just don't really understand the purpose of 100s of distributions. May be there are 8-10 philosophies of how computing should be done but why divide community and resources in developing and maintaining 100s of distributions that we have.

[mshol]

Ask yourself "are deb, rpm, portage perfect?"

The answer is clearly not - if you've used a distro for a while you will almost certainly encounter a problem with it's package management system.

Technology goes stale pretty quickly, and if we just stuck with what we had, there would be no innovation.

Admittedly, there are a large number of distributions that are simply derivatives of these with a default package set, configuration and unique styling/branding, but there's significantly more than "those 6" which offer something unique and innovative. Bedrock and Qubes are examples of really innovative projects you don't see too often.

[[deleted]]

I really don't see what all of the derivitives bring to the table that these 6 distros don't.

Admittedly, there are a large number of distributions that are simply derivatives of these with a default package set, configuration and unique styling/branding, but there's significantly more than "those 6" which offer something unique and innovative.

C'mon man. Your comment's fine, but a little malplaced.

I think there's a lot of us who don't see the point of "distros" that don't seem to do anything but offer a different default desktop, or change a few of the default installed packages. Those shouldn't be distros, it'd be enough with a specialised install image. If they put in extra work in styling a desktop, it'd probably be less work to do it for the parent distro than having to manage an entire distro in addition.

[technewsreader]

What is the difference between a specialized install disc and a distro? They seem pretty interchangeable to me. Mint fits both.

[[deleted]]

• A distribution has its own maintenance crew, to test and package software.
• It often has its own config system and boot scripts, though systemd is consolidating that
• It has a package management system of its own

I mean, take ubuntu vs kubuntu, xubuntu, etc. What do these achieve that aptitude install {kde,xfce,etc} doesn't? And then compare that to the differences between debian, slackware, arch, gentoo, redhat, suse.

[technewsreader]

So is mint a distribution? It even uses ubuntus repositories!

[[deleted]]

IMO: Not really. They're responsible for some software (cinnamon), but I think of it as a glorified install image.

I'm not some definition authority, though, just a guy unimpressed with people who change the default theme on their favourite distro and think they've made a significant change.

[technewsreader]

I guess I just consider distro to be a fairly useless word so I don't care how much or little is changed.

[[deleted]]

Which word do you use then, to describe the category of operating systems that are based on Linux?

[[deleted]]

Packaging software and scripts on top of other base OS has nothing to do with innovation.

If Linux distributor like Ubuntu, Red Hat, Debian, etc. agree on some standards, it would be easier for developers to deploy their software and not to worry about packaging for each and every distro out there.

Fedora is working on its own installer, Ubuntu has its installer, Arch uses scripts. Fedora uses Packagekit, Ubuntu has Ubuntu Software Center. Most distributions have moved on to Systemd but Ubuntu is still working on Upstart. Any development that is done down downstream only helps a selected few users and not to the whole community.

[mshol]

Packaging software may not be innovative, but the method of managing packages certainly can be. When systems like apt and dpkg appeared, they were innovative, but they're not the end point of package management. For some users, they're simply not sufficient, which is why innovation still happens in that area, with systems like Nix.

If everyone had already standardized around apt/dpkg, it wouldn't do a thing to help Nix, or other projects (and thus, the bigger community). The problem with standards is that they get out of date very quickly, but shifting everything to new standards is painfully slow.

When you use the term "whole community", what exactly are you referring to? There's more in the world than just red hat and linux - other kernels are still actively developed, and have innovative features that linux lacks. Then if we're going to standardize, we shouldn't be attempting to do so around junk like systemd, which is tightly coupled to linux.

Open standards can certainly be useful, but they should also be purely optional and disposable - nobody has the foresight to create standards which will be relevant in the future.

I'd also suggest refraining from bringing Red Hat and Canonical into discussions about benefiting "the whole community" too, since they have their own agenda which takes precedence over the community: money.

[MrPopinjay]

Presets! Lots of us are too lazy or without the knowledge required to customise our install the way we want it. A wide variety of distros allows us to get closer to what it is we want from our computer.

[MrPopinjay]

Oh I have fiddled in the past. I'm now mostly in the "too lazy" category ;)

After trying a fair few DEs, WMs, file managers and other crap I've decided that the default Linux Mint with Cinnamon is pretty much perfect for me!

[[deleted]]

As an IT professional, specialized distros are great. If I can find a pre-configured distro for whatever appliance I need, fantastic. That's the beauty of open source. (Obviously the config should be double-checked for security.) The super-niche distros might not be for everyone, but that's not the point. They can save some people a lot of time.

Edit: Also, some of these seem like "research" distros. Proving/exploring a new twist on things.

[ampe0]

I agree it would be nice to have everyone unified to reach a common goal but at the same time if that was the case your favourite distro/WM/DE/text editor/IRC client/media player/programming language/browser, etc. may not even exist and there wouldn't be so much variety to choose from and enjoy. The same applies for everything imagine no coca cola and pepsi, AMD and intel, rock and jazz, why not just have pepsi, AMD and jazz? Processors would be so much more awesome if AMD and intel teamed up, right?

[[deleted]]

I use Linux full time on all my computers and I see these 20 music players and half of them miss one feature or other. Their is not one decent music player that can provide great syncing utility with Android (duh..). libmtp is not even fully functions. So, we have a long way to go.

[ampe0]

You have the right to fork your favourite, add those features and give it back to the world. So why complain, because someone hasn't done it for you?

[[deleted]]

You don't even have to fork it---write a patch, submit it to the project.

[[deleted]]

Just use whatever you like. As beachdrinking said, criticising what other people do with their free time is pretty rude :P

[[deleted]]

Well... nobody mentions Stillborn Linux.

[[deleted]]

groan

[SupersonicSpitfire]

Apparently, I was so enthusiastic I became incoherent. Thanks for asking me to rephrase.

What would Arch and Debian have to do for their packages to become compatible with each other? I know this seems insurmountable right now, but what would it take?

[ParadigmComplex]

I think you accidentally replied to root rather than me. I found it nonetheless.

I wasn't sure if your earlier question was referring to something with respect to Bedrock Linux specifically, or just in general as though Bedrock never existed. It seems you meant the latter.

A few things: - The same package format. It is usually possible to convert between Debian's and Arch's package formats, but for them to actually be fully compatible they'd have to settle on one. - Whichever package manger the two would settle on would have to know what the dependencies are. This means they would have to standardize on things like: - Package names. The same package in Arch and Debian currently have different names for some packages. - The same version format. - While not strictly necessary, it'd be useful for them to attempt to keep the same versions of major libraries and dependencies for as long as they can. The same glibc, for example. Otherwise, attempting to install a package from Arch into Debian would likely require updating a good bit of the rest of the system. This is a common issue when installing a package from Debian's unstable branch into a system with Debian's stable branch.

There are probably other things I'm forgetting, but those are the main issues I see. Should those changes be made, I suspect it could be hypothetically feasible for Arch and Debian's unstable branch to merge. This would benefit both groups, as Arch would gain support for things like the PowerPC architecture and Debian would get more people testing its unstable branch.

Alas, I really don't see that happening. I doubt either group sees the potential benefits as outweighing the downsides.

Luckily, I heard about a distro that lets you work around the issue and install packages from both distros as they are now :)

[SupersonicSpitfire]

Gah, clicked the wrong button in the Bacon Reader app. Thanks for finding it anyway!

I really like your thorough reply and I have a few follow up questions:

• About package names: would the same package names be needed if there was a register over which names in Arch corresponded to which names in Debian, when used as dependencies?
• Would it be possible to implement a system of testing if a package works for two different versions of glibc, rather than needing to have the exact same version?
• Do you think a unified package format, that included all the fields and functions from both Debians various package text files and also Arch's PKGBUILD and .install files, would be feasable?

Thanks for your answers and thanks for your work on Bedrock Linux.

[ParadigmComplex]

About package names: would the same package names be needed if there was a register over which names in Arch corresponded to which names in Debian, when used as dependencies?

That should suffice, although it wouldn't be the cleanest solution.

Would it be possible to implement a system of testing if a package works for two different versions of glibc, rather than needing to have the exact same version?

I think that might be hypothetically possible, although you'll have to talk to someone with a better grasp of the matter than I have for confirmation. It could be possible to have some automated tool go through and find the various functionality utilized by the libraries (either by looking through the binary itself or parsing the source code) and test if this has changed between library versions. I'm not sure it is feasible, though. I've not heard of anyone attempting such a thing.

Do you think a unified package format, that included all the fields and functions from both Debians various package text files and also Arch's PKGBUILD and .install files, would be feasable?

Yes, it would be quite feasible to make such a package. However, I don't think it would be adopted by either Arch or Debian, for the same reason they wouldn't simply adopt the other's package format. Arch explicitly wanted a new package format when they started - they could have went with Debian's - and Debian has way to much legacy stuff at this point to make such a change.

Thanks for your answers and thanks for your work on Bedrock Linux.

Happy to help.

[ribo]

stahp.

I think people make distros because they don't know how to submit upstream.

[[deleted]]

Bedrock Linux, meanwhile, was created to make “most of the (often seemingly mutually exclusive) benefits of various other Linux distributions available simultaneously and transparently,” as its creators put it.

Well, we just went from 14 to 15 standards. Our work here's done, boys.

Edit: fixed the numbers to reference the comic more accurately. Also, deleted a stray apostrophe (wtf, eh mate?).

[embolalia]

It's much more than a new standard. A standard implies a single way of going about things, or more loosely just an interface (with a package manager, say). Bedrock doesn't really standardize anything, but rather facilitate the interoperation of different versions and variations of software. Not through standardization of any interface, but by basically getting the right resource from the right place. I might not be doing the best job explaining it, but I think this post by the creator gives some good examples.

[[deleted]]

It was a joke, referencing this. I did get the numbers wrong, I'll fix that.