Which distro

[Trip]

I'll vote for Debian.

Although I use an Ubuntu based distribution (Zorin) on all of my full size computers for full hardware compatibility, I use Debian on anything that needs less resources.

Being able to read any tutorial for Debian and knowing that it will be compatible with whatever system I'm using is also brilliant. Ubuntu changes way too much, even the underlying framework, and it can be very confusing for new users when a tutorial that was only written a year ago isn't even relevant anymore. I used to run the UbuntuFS site which hosts quite a few Ubuntu tutorials, but it became a real pain having to update them all every other year. All of the tutorials that I've been reading recently for help getting a Debian server running on a RaspberryPI have been bang on. Even the ones written over 5 years ago.

Another thing to bear in mind is that a lot of people that are interested in a device like the Pyra are the same sort of people that buy things like the RaspberryPi. Debian will make them feel right at home from the get go.

I don't mind distros like Arch and Gentoo, but Debian seems to be the one that's found the best balance between power, usability and hackability.

 

[Grench]

Debian Jessie - and stick with it as it becomes 'stable'.

It is 'current' now.  It will be frozen or stable around the time the Pyra ships.

Perfect platform to develop for and 'use' for 18+ months.

 

[_wb_]

^

D) Edit on sshfs-mounted directory (EDIT: Oh, probably what you meant by A)

E) (if possible, my preferred method) Most of the time only transfer files through git, test small changes as much as possible on the desktop, debug pandora-specific stuff using option D

EDIT: Oh, and compiling using distcc in a chroot (urjaman's dchrt)

You forgot:

F) Edit on the Pandora/Pyra directly, using its own keyboard and screen, no need to hook up anything. This is my preferred method. You can easily get 80x25 characters readable, which was the usual text mode in the nineties. I started coding on the C64, which had 40x25 text mode on a 320x200 pixel screen. Coding with 100x28 characters on a 800x480 screen is way more comfortable

 

[Linux-SWAT]

Use SOLEIL and have a ready-to-use x86_32, x86_64 and ARM distcc cluster, and develop for each arch on any arch with almost no setup.

Can be ported on any other distro than Slackware, but i probably won't do it.

 

[second exodous]

I'm surprised no one has made a poll on this, this forum loves poles.

 

[Ethelif]

I know this almost warrants being flamed over but what about Fedora?  As of Fedora 20 it supports ARM Architecture.

 

[Askarus]

Use SOLEIL and have a ready-to-use x86_32, x86_64 and ARM distcc cluster, and develop for each arch on any arch with almost no setup.

Can be ported on any other distro than Slackware, but i probably won't do it.

It would be my dream to have this on Pyra's default OS.

 

[Ziz]

I know this almost warrants being flamed over but what about Fedora?  As of Fedora 20 it supports ARM Architecture.

Fedora is meant for users with knowledge. They try to add brand-new features and it may break from time to time, but on the other hand you get really recent stuff. A bit like Debian SID, but with release cycles. I think <something else> stable is better.

 

[pmprog]

^

D) Edit on sshfs-mounted directory (EDIT: Oh, probably what you meant by A)

E) (if possible, my preferred method) Most of the time only transfer files through git, test small changes as much as possible on the desktop, debug pandora-specific stuff using option D

EDIT: Oh, and compiling using distcc in a chroot (urjaman's dchrt)

 You forgot:

F) Edit on the Pandora/Pyra directly, using its own keyboard and screen, no need to hook up anything. This is my preferred method. You can easily get 80x25 characters readable, which was the usual text mode in the nineties. I started coding on the C64, which had 40x25 text mode on a 320x200 pixel screen. Coding with 100x28 characters on a 800x480 screen is way more comfortable

Yeah, but on the C64, your variables were only allowed to be two characters long. These days you (can) have variable_that_contains_important_integer.

Whilst I'm not sure the screen bothers me, I personally find the Pandora's keyboard quite awkward for programming, because of where the brackets and braces are.

 

[EvilDragon]

Use SOLEIL and have a ready-to-use x86_32, x86_64 and ARM distcc cluster, and develop for each arch on any arch with almost no setup.


Can be ported on any other distro than Slackware, but i probably won't do it.

It would be my dream to have this on Pyra's default OS.

I don't have much experience with Slackware, to be honest.


Is package management / ease of use / etc. As good as on Debian?

 

[Askarus]

Use SOLEIL and have a ready-to-use x86_32, x86_64 and ARM distcc cluster, and develop for each arch on any arch with almost no setup.

Can be ported on any other distro than Slackware, but i probably won't do it.

It would be my dream to have this on Pyra's default OS.

I don't have much experience with Slackware, to be honest.


Is package management / ease of use / etc. As good as on Debian?

As I understood we don't need Slackware (see bold marked text).

Dabian can do it as well.

(Please correct me if I did understand it wrong).

 

[ExquisiteCorpse]

Not unless you enjoy compiling everything from scratch and the fact Slackware is essentially managed by one guy.

Debian has the most amount of developers working on it and gets my vote purely for the amount of packages availble, the stability, the fact they don't shit on their users (Canonical/Ubuntu) and they're vision.

They support the widest variety of architectures and they have the biggest package base.

 

[Askarus]

I talk about SOLEIL like usage, not using Slackware as main Distro.

SOLEIL: Booting any PC with any Arch from the Pyra.

 

[Linux-SWAT]

One of the Slackware package management tool called slapt-get and it's GUI gslapt behaves exactly like Debian's one. So from a user POV there's absolutely no difference.

All the job is done by the package maintainer, compilation, dependencies marking.

Compilations are easy with sbopkg, which is a BSD's port-like system. Dependencies marking is not yet automatic and takes a bit of time (i don't do that for my 450+ packages).

To resume, it's exactly like Debian, except that under Deb, the hard work is already done by others.

Debian is the right approach for the Pyra, and like Zaxxon on OP, i'll probably keep it as a backup OS on NAND.

But Slackware is more stable and manual, so things break less. I prefer to work like this.

Also there's no 147 dependencies installed when you want a simple program to run.

What i fear with SOLEIL on Debian, is the breakage when doing updates, but it probably can be avoided.

 

[Linux-SWAT]

Not unless you enjoy compiling everything from scratch and the fact Slackware is essentially managed by one guy.

Well it's all automatized, i basically let my OP compile during three days, and put the packages in repositories.

Apart a few interruptions (source server down, compile fail, new dependencies on the "playlist) it's a non-work.

Of course, doing updates requires additional time.

Not to mention that i compile all my packages with

   export CFLAGS="-DPANDORA -O2 -pipe -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fPIC"


   export CXXFLAGS="-DPANDORA -O2 -pipe -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fPIC"

So it's probably better than Deb regarding optimization :^).

One guy and many contributors. Actually, all that hard work on x86_64 development was done by another guy. Same for Slackware ARM.

 

[Askarus]

One of the Slackware package management tool called slapt-get and it's GUI gslapt behaves exactly like Debian's one. So from a user POV there's absolutely no difference.

All the job is done by the package maintainer, compilation, dependencies marking.

Compilations are easy with sbopkg, which is a BSD's port-like system. Dependencies marking is not yet automatic and takes a bit of time (i don't do that for my 450+ packages).

To resume, it's exactly like Debian, except that under Deb, the hard work is already done by others.

Debian is the right approach for the Pyra, and like Zaxxon on OP, i'll probably keep it as a backup OS on NAND.

But Slackware is more stable and manual, so things break less. I prefer to work like this.

Also there's no 147 dependencies installed when you want a simple program to run.

What i fear with SOLEIL on Debian, is the breakage when doing updates, but it probably can be avoided.

As long as the NAND is big enough and you keep up the good SOLEIL work for Pyra as well I don't mind using Slackware as second OS.

For now I don't use it any more as my SD-cards are full of other stuff.

Hoping for 256 GB cards to become cheaper.

 

[_wb_]

Hoping for 256 GB cards to become cheaper.

Since only Lexar seems to make those, they can use their monopoly to charge too much for them, at the moment they are $449 on Amazon.

But 128GB is quite a lot already. You can get two fast 128GB cards from a cheaper brand for $160 (so $80 each) at the moment on Amazon:

http://www.amazon.com/Komputerbay-PACK-Digital-Extended-Capacity/dp/B00D09ACL0/ref=sr_1_49?s=pc&ie=UTF8&qid=1392122441&sr=1-49&keywords=SD+card

My guess is that by the time the Pyra is released, Lexar will no longer have a monopoly on 256GB cards (maybe they will have the first 512GB cards and have a monopoly on that, who knows), and you will be able to get them for less than $200. In any case, with two fast SDXC slots, the Pyra will be future proof for a long, long time. Digital (video) cameras with their ever increasing resolutions and framerates create a lot of demand for ever faster and bigger cards, and we can only profit from that.

 

[bzar]

Come oooooon 512GiB cards before pyra is released

We won't be hitting 2 TB for a long, long time. I will eat my hat if we don't see a Pandora2* before SDXC cards larger than 256GB.

*offer void if OpenPandora dies before a Pandora2 can be produced.

ref

 

[Askarus]

Hoping for 256 GB cards to become cheaper.

Since only Lexar seems to make those, they can use their monopoly to charge too much for them, at the moment they are $449 on Amazon.

But 128GB is quite a lot already. You can get two fast 128GB cards from a cheaper brand for $160 (so $80 each) at the moment on Amazon:

http://www.amazon.com/Komputerbay-PACK-Digital-Extended-Capacity/dp/B00D09ACL0/ref=sr_1_49?s=pc&ie=UTF8&qid=1392122441&sr=1-49&keywords=SD+card

My guess is that by the time the Pyra is released, Lexar will no longer have a monopoly on 256GB cards (maybe they will have the first 512GB cards and have a monopoly on that, who knows), and you will be able to get them for less than $200. In any case, with two fast SDXC slots, the Pyra will be future proof for a long, long time. Digital (video) cameras with their ever increasing resolutions and framerates create a lot of demand for ever faster and bigger cards, and we can only profit from that.

I don't think so.

Those cards are out since end of 2012.

Others are not making those cards as since a long time.

Lexar is holding the monopoly for a long time already.

 

[_wb_]

Hoping for 256 GB cards to become cheaper.

Since only Lexar seems to make those, they can use their monopoly to charge too much for them, at the moment they are $449 on Amazon.

But 128GB is quite a lot already. You can get two fast 128GB cards from a cheaper brand for $160 (so $80 each) at the moment on Amazon:

http://www.amazon.com/Komputerbay-PACK-Digital-Extended-Capacity/dp/B00D09ACL0/ref=sr_1_49?s=pc&ie=UTF8&qid=1392122441&sr=1-49&keywords=SD+card

My guess is that by the time the Pyra is released, Lexar will no longer have a monopoly on 256GB cards (maybe they will have the first 512GB cards and have a monopoly on that, who knows), and you will be able to get them for less than $200. In any case, with two fast SDXC slots, the Pyra will be future proof for a long, long time. Digital (video) cameras with their ever increasing resolutions and framerates create a lot of demand for ever faster and bigger cards, and we can only profit from that.

I don't think so.

Those cards are out since end of 2012.

Others are not making those cards as since a long time.

Lexar is holding the monopoly for a long time already.

Yes, but others have been catching up (they all make 128GB cards now, that was not the case one year ago). The prices of 128GB cards have dropped significantly. Those Lexar 256GB cards also became cheaper: when they were first announced, they were $900. My guess is that they will drop a bit more, Lexar will announce the first 512GB card with an initial price tag of $900 or so, other will start to make 256GB cards and their price will drop further.

I'm currently still using 16GB, 32GB and 64GB cards, because those had the best GB/$ ratio when I bought them.

SD cards can be easily swapped, so even if their capacity gets stuck at 256GB, it's not too bad. A heap of SD cards does not take up much space. It beats a box of 3.5" floppy disks (1.44MB each) any day