Porteus changing distro

[dustbunnies]

From an outsider's perspective, http://distrowatch.com/search.php?basedon=Slackware
Porteus and Salix seem like the only appealing nodes in the slack-derived branch of the linux family tree.
Salix seems to be experiencing doldrums (devs are bored? devs are sitting tight, awaiting slack v.XX release?) and Porteus seems to be following the same course. Porteus now has X Y Z (er... K G X) desktop-flavored versions, so now what? Where to go from here?

My humble suggestion to the Porteus devs and community members, regarding the prospect of "Porteus changing distro"
would be to explore, and embrace, common ground with these good folks:

Puppy Light-Debian-Core-Live-CD-Wheezy + Porteus-Wheezy
http://www.murga-linux.com/puppy/viewto ... start=1065
(FWIW, I'm NOT a puppy user)

[jimwg]

For me, I'd simply say Porteus should accommodate the under-the-hood techie, but allow a user to use it off the bat without ever having to so much touch a command line or script. Mac and XP proved this was doable ages ago. Bottom line, the newbie doesn't nor shouldn't care what distro it is as long as it fits the bill to satisfy their desire to; 1. have as much variety in Linux software accessible, 2. Make it virtually automatic and invisible to install and update that stuff, 3. be able to perform nifty desktop/window tricks with minimial set-up, 4. cosmetically pleasing in screen features. In Linux, Mint and Puppy are the closest so far in terms of software offerings and PPM ease, but otherwise Porteus leaves them behind.

Jim in NYC

[KnallKopf]

Porteus with Slackware is the best OS on the World for desktop-PCs.
The leaders of the community have done a great job.
Thanks.

All things work out of the box.
If a package is missing, it s easy to build your own package.

In Debian constantly missing a packages, the most includes and libs on wrong places and you can write a roman to the CFLAGS.
So were at least my past experiences.

[tome]

new package would be downloaded and converted to xzm -> old one would be deactivated and removed -> new one would be moved to /porteus/modules (or extramod=) and then activated

but I thought about system updates i.e. security updates for network manager - it must be repacked xorg module but new base module is available only for new Porteus version and Ubuntu has system-updates every few weeks or days.

The same thing can be done also for rolling-release:
if one package would be one base module (or few packages in one module according to i.e. frequency of updates/releases, size, necessaries, need for proper work of new apps) then it should work similar you "mentioned":
new package would be downloaded and converted to xzm -> old one would be deactivated and (re)moved -> new one would be moved to /porteus/base and then activated.
Ca 20-30 base modules could be accepted and it would be easier repack smaller modules. More than 30 base modules won't be accepted due to longer boot up. Some modules don't need be inserted to aufs, they can be easily mounted but in inserted module should be links to files in this mounted module - it is quicker, links have ca. 0 bytes and mounted module can be easily replaced with new one. BTW why we have kernel, core and xorg modules instead of one, two (kernel, core+xorg) or more smaller ones?

Second but not modular way is to unpack and move content of base modules to changesbase - system updates should be in this new first changes folder, second changes folder would be i.e. for Porteus customizations and third - as it is now. But it requires modification of start up scripts (more than one changes folder) and new script to share system and user changes to different folders - to much work.

[brokenman]

BTW why we have kernel, core and xorg modules instead of one, two (kernel, core+xorg) or more smaller ones?
Obviously the kernel module is separated so the kernel can be upgraded easier. The core and xorg modules are separated so that people can build a 'text mode only' version of porteus (they don't need xorg).

[ztealmax]

I can understand the feeling of wanting something more something is allways greener on the other side however
what we have is damn good, so if packages are missing and not available on this distro its based on well lets pull together and make them available
for this distro, i like this good distro what porteus is based on specially now since i got valve steam working with smaller hickups *GL Rendering but im working on that


Cheers
Ztealmax

[fanthom]

Ubuntu has system-updates every few weeks or days.

dont forget that Shuttleworth has thousands of employees and is pumping millions USD every year in Ubuntu

Some modules don't need be inserted to aufs, they can be easily mounted but in inserted module should be links to files in this mounted module - it is quicker, links have ca. 0 bytes and mounted module can be easily replaced with new one.

someone suggested similar idea but it was long time ago and i never seen this working in porteus so can't say how much efficient it would be. looks bit complicated - maybe you could do some work in this direction?

[jimwg]

Just a newbie question:

If chosen, how fast can a new distro be implemented on a Porteus version?

Jim in NYC

[ztealmax]

Yea im aksing the same question if its not long time to make it i could go with ubuntu lts with MATE or stay on slack

[brokenman]

If chosen, how fast can a new distro be implemented on a Porteus version?

It's really impossible to know since it hasn't been done yet. It wouldn't be a short time since all maintainers need to learn the new distro. Having a base in slackware makes it easier to work under the hood but we still need to learn all about the new platform.

[fi5ban]

after looking more into to this as much as slackware is awesome it looks like debian would help expand porteus
package needs to

[ViktorNova]

I think going with Debian as a base system would be a really good move for Porteus.

It's stable, lean, and super widely tested, and of course has a very large amount of software ready to install. It is also one of the most deployed server distributions, and there are a number of good add-on repos for more modern stuff not found in mainline (like up-to-date node.js, etc). It would be really cool to not have to devote nearly as many dev resources to packaging common software and be able to focus on new things to make Porteus even more awesome. A package manager that has one solid method of downloading packages (as opposed to the current 5 or so , resolved dependenciesx, and packaged debs into .xzm modules all on it's own would be beautiful. I think a move to Debian would really make Porteus usable by the general public, which would just be cool because so many non-geeks would really benefit for Porteus' turbo speed, modular, run from memory way of doing things (and not have to dive into the intimidating world software compilation when an app they want is not in the repo)

Debian has also been chosen as the official base of SteamOS http://store.steampowered.com/steamos/buildyourown ..it's stable enough for Valve! Valve will be contributing more and more to Debian, and we would get those benefits immediately

Debian also just a week or 2 ago officially chose to use systemd as it's default init system starting in the next stable release https://www.docker.io/, joining Red HatFedora, SUSE, and Mageia in this big move to bring Linux to the next level. Porteus could ride those coattails into the future!

Slackware is also one of the only major linux distributions (to my knowledge, if not the only one) that can not support Docker, which is already starting to make a major impact in the server space and is most likely going to be a really big deal in the near future https://www.docker.io/



Finally, I propose an important question: What does Porteus lose by switching to Debian as a base?

[roelof]

I agree.

I played a little bit with docker and I think this could be a better way to handle the modules.
Every module can be a sort of layer which can be more easily be updated then the current way as far as I can see.

If someone wants to help me , maybe we can try if this can work.

Roelof

[ponce]

http://slackbuilds.org/repository/14.1/system/docker/

[brokenman]

Looks interesting. Perhaps the designer is a 'dockie' (one who works on a shipping dock) as the documentation makes/has many references and images of shipping containers. This could be the start of a structure of a unified linux packaging system that is so sorely needed.