version control: git
pkg management: tar.gz containing fakeroot installs

Next subject ? :P

Let me get this straight. At the moment, we're planning a distro with:

• BTRFS by default
  
• Init which isn't systemd
  
• musl libc
  
• GNU coreutils (as opposed to busybox)
  
• Package system similar to Slackware's (gzipped tarballed fakeroot installation)
  

Could someone important make a Nixers GitHub organisation and a repo with a wiki where we can write everything down? I could do it, but that wouldn't be official enough.

I could host the nixers github group but dami has a git server up already. He needs to setup a web interface though.

Also, you guys should use pkgsrc.

I second pkgsrc!

z3bra Wrote:version control: git
pkg management: tar.gz containing fakeroot installs

Next subject ? :P

Sure git :P. I personally would prefer an ports like, git controled system that uses make scripts like PKGBUILDS or slackbuilds. Just because its easy to maintain, easy to use and very modular. I dont know that much about pkgsrc; used it a time with Arch; but a totally nixers.net driven ports tree would be nicer imo. In that way its easy to make it rolling which simply awesome.
We can use two branches, a rolling and a "stable".
Then we need a database and a chroot install script to create the base system.

So that would be my recommention

I'm with you on the port-like system ! Here are the pros:

• Everyone can see the recipe to build <package>
  
• It is easier to recompile a software according to your needs
  
• If a package don't build anymore, anyone can submit a new "recipe" ...
  
• ... and mail this recipe to the maintainer of this package
  
• Automation of the building system is easy
  
• Anyone could share pre-compiled packages with the community
  
• Shell scripts (for the recipes) are easier to write than Makefiles
  
• That'd be cool to have OUR package list :)
  
• Could make rollback easier if every port is git-versionned
  

Let's go for the cons:

• Users need to compile their softwares (if nobody built 'em before)
  
• Community driven package system (like AUR / Contrib)
  
• Create a directory tree on the user's system
  
• Rolling-release is MANDATORY
  

Wouldn't just including pkgsrc and pkgin with our distro be the best idea? We'd get free access to 12000 ports and we could just build the ports using something like dpb on OpenBSD or poudriere on FreeBSD. I'm not sure what the NetBSD one is for pkgsrc, but I'm sure they have something similar we could use to build all the ports, put them on a file server, and point pkgin there by default.

Remember Greenspun's 10th rule: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." and just replace "C or Fortran program" with OS and "Common Lisp" with ports. I think we'd just end up creating a shitty, buggy version of pkgsrc (in any case something worse than the very good pkgsrc) anyway if we tried to roll our own.

I don't know of any Linux distros which have pkgsrc and pkgin as default, so that would make us unique, unless there are distros I'm forgetting. So I think we should:

• Fork pkgsrc
  
• Go through all the popular ports and make sure it all works on Linux
  
• Patch anything that doesn't work (probably won't be that much stuff)
  
• Regularly merge changes from the real pkgsrc tree
  

Considering that most of the programs in pkgsrc already work on Linux, it'd be almost zero effort.

Its easier to create package-managment tailored to our system, so we dont have to deal with bugs or failings of other devs. Just make it our own is easier to manage then being in a depency of a package-managment made for another system.

So build scripts are easy to write and easy to add to the git repo and git is alredy a good tool to fetch and update anything you need. The only thing we need is a database ( or a file that contains every file that is installed with full path; and another file that contains prog name and version or bla)

So it would be just a few easy to maintain textfiles and a parser that reads and execute the build file.

pkgsrc has been written to be portable and works on Linux already. The way I see it, we have two choices, each with some pros.

Make our own package management:
Pros:

• Don't have to rely on other devs
  
• Only a few text files to maintain
  

Use pkgsrc:
Pros:

• Don't have to do any work
  
• 12000 ports already made for us
  
• Full-featured binary package manager already made for us
  
• Tried and tested system
  

Making our own package manager or ports system is a monumental undertaking and shouldn't be taken lightly. It's easy to say that a new ports tree would be easy to maintain, but really, it wouldn't be - it'd just turn into a nightmare.

I don't actually speak from experience, so someone who really knows what they're talking about is free to correct me.

I agree with what's said above, and pkgsrc has 14000 ports ! It also features package signing.

Personnaly, I just like the idea to say "Yeah, we made that package manager matafuka!"

Maybe we could start with pkgsrc, and work on an alternative pkg manager that we could implement later, when the distro will be fully working ?

Yeah, a package manager would be a cool project, but the distro comes first. I think a package manager would definitely make a good project for the future. So when do we start? Will Ichiban put it all up on GitHub or are we doing something else?

I see this like zbruh. There's nothing wrong with creating a package-managment thats perfectly integrated and tailored for our distro. So we don't have to deal with software thats not developed for our needs.

Thats why we start creating a distro; because we want some kind of OS that contains exactly that what we need and what we want. And if we use a "not-self-made-packagemanager" then we do not need to create an entire distro.

//edit

Contains pkgsrc everything a distro needs, or do we need precompiled packages? I used pkgsrc one time on Arch and was not able to make an entire Linux distro with it.

Well on Slackware, you can remove the package manager and all the packages, replace it with pkgsrc, reinstall everything and it works fine. Of course, the coreutils, kernel, important system programs, init system and all that don't come with pkgsrc, all of the actually interesting stuff will be left to us to implement. I think it's really important we don't get a case of NIH and try to make everything ourselves for no concrete reason and for no benefit.

Well, you can remove the package.manager from every distro; but that was what I'm asking. If pkgsrc not includes all software you need for a base system, then its important to create precompiled packages of everthing you need to do stuff. And thats exectly that why I prefer to not using pkgsrc for a rolling linux distro.

At first we have o figure out how to compile every base package to using musl instad of glibc. But the most important question at this moment is:

Who the fuck will do all this at the first time. Who has the time and the resources to make an installable prototype?

Well, anyone who can be bothered to make an LFS system using that book, but swapping out glibc for musl, and the init system for something better could make a start on something, which is probably what Ichiban has done.

You raise a good point with pkgsrc and a base system, but we could just fork pkgsrc and add base packages. I don't see why that wouldn't work.

I did read the musl FAQ and its very easy to create a musl libc system. Only thing you must have is normal working toolschain; then just make musl and use the musl-gcc for comiling.

To pkgsrc > I did not say it wouldn't but I don't know how to add packages to pkgsrc but if its easy we can use it for first. But I'm still in the opinon that "no own packmgr, no own distro" :P.

If someone added the packages added to pkgsrc we need just need to way to install packages with pkgsrc from a chroot; and nobody needs to build an lfs.

We can use a xyz-linux-live-cd and follow the basic "arch install".
Just make a few things our own like build the basic filesystem and such stuff.

As init system we can use the init style "Starch" uses.

Reference: https://github.com/StarchLinux/ports/tre.../itscripts
https://github.com/StarchLinux/itscripts
https://github.com/StarchLinux/initscripts

And of course the most important one
https://github.com/strake/init

minirc + sinit \o/

The guys at 2f30 did a really good job with their "Toy distro", morpheus. Definitely worth checking out: http://git.2f30.org/

Oh right; just forgotten sinit exists.

sinit ftw

Will this project be going ahead, or has it turned into vaporware? If it's the latter, then shouldn't we try to have a community project which is less ambitious than a whole distro?

(07-04-2014, 08:04 AM)pizzaroll1 Wrote: Will this project be going ahead, or has it turned into vaporware? If it's the latter, then shouldn't we try to have a community project which is less ambitious than a whole distro?

I made a proposal for a browser :D

But I do wish this distro will get off the ground.

A distro would obviously make a good project. But I'm not sure the community is ready for something that huge already.

We don't know the skills of many people when it comes to programming, versionning, managing a distro. I personnally never set up an LFS, and I have no idea on how to create a base distro from scratch. I can setup an init system, fire up some services and such... But I have no idea about what *REALLY* happens between the bootloader and the first line that show up in the TTY.

ATM, I think that a smaller project would be a better bet. The problem will then be: WHAT?

A browser, a WM, a firewall, a panel, a notification system, ...

What about a super minimal (almost) DE. ie, one package with a WM, panel, notification system.

my biggest gripe with wm's now is that you have to hack together not necessarily cohesive elements to get what you want.

(08-04-2014, 10:49 AM)rudylorren Wrote: What about a super minimal (almost) DE. ie, one package with a WM, panel, notification system.

my biggest gripe with wm's now is that you have to hack together not necessarily cohesive elements to get what you want.

To keep it minimal we could write it in javascript.

^.^

(08-04-2014, 11:37 AM)jobss Wrote: javascript.

nah

@jobss, and as it's minimal, tiny, but strong, let's call it GNOME DWARF !

rudylorren Wrote:What about a super minimal (almost) DE. ie, one package with a WM, panel, notification system.

Impossible because that's the exact opposite of minimalism. At first, you ship a WM + panel, but then you'll add a notification system to add "cohesion", and to make it easier to use, default applications. Oh, really light applications obviously! We're shipping something minimal after all. And to make it even more minimal, we can rewrite every app by ourselves, using a single library that we will create!

*BAM* you're the GNOME team. Minimalism IS minimalist because a single user pick whatever he wants, and sort every app

:) good point

(08-04-2014, 12:09 PM)z3bra Wrote: @jobss, and as it's minimal, tiny, but strong, let's call it GNOME DWARF !

rudylorren Wrote:What about a super minimal (almost) DE. ie, one package with a WM, panel, notification system.

Impossible because that's the exact opposite of minimalism. At first, you ship a WM + panel, but then you'll add a notification system to add "cohesion", and to make it easier to use, default applications. Oh, really light applications obviously! We're shipping something minimal after all. And to make it even more minimal, we can rewrite every app by ourselves, using a single library that we will create!

*BAM* you're the GNOME team. Minimalism IS minimalist because a single user pick whatever he wants, and sort every app

Elementary is kind of doing the same thing too.

Dwarf, would be a cool name for whatever DE project that would be produced.

Elementary, Gnome, XFCE, LXDE. That's the leitmotiv of every DE maker