GOAL

[0b01]

I have studied why the other OS developed by /g/ failed. Technically, most of them, if not all, were parochially successful with a few stable .iso releases but they failed to leave prints on the sands of time. Lo/g/os cannot be another Jiyuu or Clover OS, which failed because they have nothing to offer: _merely changing the name, logo and adding a few bloatwares is plagiarism and ultimately meaningless_. Lo/g/os, is a customizable Archlinux that can be installed like Ubuntu. You choose WM theme and choose Firefox theme and choose VIM theme and you are done

Lo/g/os offers a db full of custom themes: pre-configured packages installed with a simple command(rice vim-light or rice openbox-mlp) like pacman.

What do we need to build?

• a rice db / repo
• a Package Manager for rice db (can also be used on other distros)

What is lo/g/os?

• a bloatware-free Arch distro with an installer and UI manager

Who is lo/g/os for?

• anyone who needs a quick installation of Archlinux
• anyone who needs a riced theme

How do you propose we achieve this?

• The arch way: _does exactly what it needs to, no extras, bloat, no choosing for the user_
• Any ricable config is uploadable

[rr-]

A strong candidate for rice db's platform would be hosting it on Github. If you look at vim, it has its vim.org. But do people use that? Nope, they use things like vundle and pathogen, where you can just add plugins to your .vimrcs by supplying links to their respective Github pages.

Pros:

• no need for dedicated server(s) = no disputes about $
• no need for sophisticated moderator structure - a hierarchy could be established naturally, through number of contributions
• no need to advertise the platform too much, if it's on Github, people will find it
• no need for accounts outside Github, and having Github account nowadays is reasonable

A few questions remain:

• should plugin source code be integrated into one central repository?
  • yes:
    • people know their options (no need to google for new plugins, it's all there in one place)
    • bloatware, downloading such repository will take ages after a while
    • pull requests will become PITA for owners really fast
  • no:
    • people need to google for new plugins
    • secure
    • people download only what they want
    • need to enforce installation standards (I remember node.js or something else had a bot that whined to repo owners when it couldn't find package.json or something - it was actually useful)

Also, if we decide on letting people host plugins in their own separate repositories, a reasonable idea to consider is creating something similar to oh-my-zsh, where people list (in this case, just list) their favorite scripts. That way, people wouldn't need to google for new plugins anymore. This could become Github Pages repository, so that it could have nice frontend without need for a server.

I vote for the last option, with creating community-driven "stepping stone" repository linking to all the goodies. (Note that this idea is mostly compatible with your rice install vim-mlp syntax, but it would need to be changed to rice install vim-scripts/mlp.vim to make up for no index server.)

Leaving $ aside, having no index server is also good with regard to possible downtimes and bandwidth usage, which are more likely to be a problem in non-corporate environments.

[Luminarys]

Thanks for the tips. This is actually exactly what we plan to do for hosting, with our servers performing two functions:

1. Serving out regularly updated indexes to clients
2. Accepting requests to upload a new rice by clients and processing them before putting them into a github repo and updating the index
   In answer to your questions about centralization of repos, the github repos are a bit more restricted than you think. Because riceDB will be moving files around your computer and downloading from the internet, the system will be setup in such a way that only the server will have access to modifying the github repos. Clients will have to interface with the server so that the server can perform validation checks on what they upload to verify that it's safe, not plagiarized/a duplicate, etc. We will allow for 3rd party repos to be hosted, but they will not be part of the official index file and we will have to ask for user confirmation upon installing them. There will be a web frontend as well as a CLI for uploading and downloading rices, though we are focusing on developing the CLI for now.

I'm glad to see our project is getting some attention from the creator of the mal graph, please keep on doing god's work and feel free to leave any more comments/suggestions.