P2 Slackware as default?


The unit will come preinstalled and ready-to-use like the current Pandora.

And there will also be full-flash images ready, same as before.

By default, we'll most probably have the Debian stable repositories enabled, but anyone can switch them to testing, unstable or even experimental.

It's up to the user whether he wants bleeding edge but might have to reinstall the unit or whether he wants it safe and stable.

We'll keep our own enhancements in our own repository, which will (of course) also be enabled as default.
 
The unit will come preinstalled and ready-to-use like the current Pandora.And there will also be full-flash images ready, same as before.By default, we'll most probably have the Debian stable repositories enabled, but anyone can switch them to testing, unstable or even experimental.It's up to the user whether he wants bleeding edge but might have to reinstall the unit or whether he wants it safe and stable.We'll keep our own enhancements in our own repository, which will (of course) also be enabled as default.
What about Android
 
Will need to be a community effort like the current implementation on pandora
Cyanogenmod is taking a business approach to their releases: you can now pay them to build and maintain an Android release for your system. This may be something worth looking into. It'll probably turn out to cost far more than it'd actually be worth but it doesn't hurt to investigate.
 
KDE is very Win95 feeling and has kind of fallen out of favor the last few years.
[quotation needed]
You want me to quote someone else to validate my own experience of having installed and tried to use it for a few days? My experience was that it was clunky, hard to find settings and kept trying to default back to settings I didn't want. Just like Win95 used to. I recall that I had to go through something like 4 different areas of configuration and multiple sub-configurations just to un-map OS functions from the F1-F12 keys so they would return to functionality in other programs.
No, I wanted you to quote some source for the "fallen out of favor the last few years" part. KDE is doing very well.
The general keyboard shortcuts are ALL in System Settings > Shortcuts and Gestures. There you'll find a nice categorization to custom, global and application level shortcuts. Given that SOME default bindings are needed and they will not please everyone, some- like yourself -will always end up rebinding everything. Could you outline how you think it should be done? If you want to nuke a lot of settings at once, you can always edit ~/.kde/share/config/kglobalshortcutsrc. The base use case is changing a few settings.
I don't -want- a categorization sub-menu for each different topic that I have to hunt through a 3 page list to find out what they mapped to a key.

How it should be done:

1. An OS UI should NEVER take precedence over the foreground running program.

2. An OS should NEVER take control over 'normal', 'control' or 'shift' + function key. Those have historically been reserved for -program- use.

For mapping, I should be able to go into that configuration menu, select a button to activate a search of the piles of configuration pages, enter the key I want to see the binding for - and have it go there. Not search through one page at a time - through all of the pages - to find what the OS has mapped to shift-F11 so I can de-bind it so it doesn't override my foreground running programs.

It bugs the hell out of me when OS UI designers assume that the OS interface is the end product. Keep the OS out of my applications.
 
The unit will come preinstalled and ready-to-use like the current Pandora.

And there will also be full-flash images ready, same as before.

By default, we'll most probably have the Debian stable repositories enabled, but anyone can switch them to testing, unstable or even experimental.

It's up to the user whether he wants bleeding edge but might have to reinstall the unit or whether he wants it safe and stable.

We'll keep our own enhancements in our own repository, which will (of course) also be enabled as default.
Perfect as usual Sir.

Thank you!
 
Going deep into offtopic.

I don't -want- a categorization sub-menu for each different topic that I have to hunt through a 3 page list to find out what they mapped to a key.
Well, I do. Guess that's a matter of taste.
How it should be done:

1. An OS UI should NEVER take precedence over the foreground running program.
Don't most DE/WM do this, unless the application explicitly consumes the keypress? I may be completely off here, as I haven't really paid attention to this in the past.
2. An OS should NEVER take control over 'normal', 'control' or 'shift' + function key. Those have historically been reserved for -program- use.
Is there some standard or guideline about this? Or is it just "at least environment XYZ did it"? Not saying it would be a bad thing if the default keybindings didn't use those, but if it's just word of mouth information it's kinda hard for everyone developing interfaces to know. I know I didn't have any knowledge of such a convention, but that may be just me.
For mapping, I should be able to go into that configuration menu, select a button to activate a search of the piles of configuration pages, enter the key I want to see the binding for - and have it go there. Not search through one page at a time - through all of the pages - to find what the OS has mapped to shift-F11 so I can de-bind it so it doesn't override my foreground running programs.
Well, it does have per-module search you can enter the key combination or a part of it into, but I agree a global search for them would be nice.
It bugs the hell out of me when OS UI designers assume that the OS interface is the end product. Keep the OS out of my applications.
This is by all accounts a valid point of view.
I'm not trying to antagonize you here, just learn why you don't like the DE I use daily at work and at home. For each their own, I guess. :)
 
Going deep into offtopic.
Probably, but I think ED has already answered the topic. Special repository of Debian Stable + whatever is needed to make it work right on our hardware. Perfect.
We can still cuss and discuss what the DE is going to be.

I don't -want- a categorization sub-menu for each different topic that I have to hunt through a 3 page list to find out what they mapped to a key.
Well, I do. Guess that's a matter of taste.
It depends on which direction you're approaching it. If your objective is to bind something to a key, the categorized basis probably works fine for you. Flip that around though and it becomes a POS. If you need to find out the answer to: "WTF? Why doesn't Ctrl-F11 work in this application?" it can be an intense source of frustration. First you'll wind up trying to figure out what broke in the application. Then you'll search online for the application help to see if anyone's encountered the issue. Then you may or may not stumble on someone else with another application noting how the OS has taken over that key-mapping. Then you have 20+ minutes of scrolling through those categories, list by list, line by line, to figure out what the OS designers decided to map that key to.
How it should be done:

1. An OS UI should NEVER take precedence over the foreground running program.
Don't most DE/WM do this, unless the application explicitly consumes the keypress? I may be completely off here, as I haven't really paid attention to this in the past.
The DEs started to default to over mapping applications and defaulting to massive 'hot key' mapps right after Unity hit the scene. Prior versions of Ubuntu with Gnome didn't have the issue. Current versions of Gnome are nearly as bad as KDE in this respect, but the existing mappings are easier to find.
2. An OS should NEVER take control over 'normal', 'control' or 'shift' + function key. Those have historically been reserved for -program- use.
Is there some standard or guideline about this? Or is it just "at least environment XYZ did it"? Not saying it would be a bad thing if the default keybindings didn't use those, but if it's just word of mouth information it's kinda hard for everyone developing interfaces to know. I know I didn't have any knowledge of such a convention, but that may be just me.
Prior to about 2 years ago, this was an unwritten convention. Most desktop word processors were based on WordPerfect & MS Word, both of which make extensive use of the function keys. Most spreadsheets were based on Lotus 123 and Excel, both of which make extensive use of the function keys. Many of the adventure and FPS games prior to WoW used the function keys and alt,shift,ctrl combinations with them for different in-game features.
Having the DE steal the function keys from the application is a relatively new trend.

For mapping, I should be able to go into that configuration menu, select a button to activate a search of the piles of configuration pages, enter the key I want to see the binding for - and have it go there. Not search through one page at a time - through all of the pages - to find what the OS has mapped to shift-F11 so I can de-bind it so it doesn't override my foreground running programs.
Well, it does have per-module search you can enter the key combination or a part of it into, but I agree a global search for them would be nice.
Per-module search. If you have gone far enough down the rabbit hole to figure out it is the OS and not your application that is breaking the application, AND if you know the function key that's frotzed by the OS but don't know what function it got mapped to or how that would be classified, you still have to find and go through each and every module to figure out what's eating your app.
It bugs the hell out of me when OS UI designers assume that the OS interface is the end product. Keep the OS out of my applications.
This is by all accounts a valid point of view.
I'm not trying to antagonize you here, just learn why you don't like the DE I use daily at work and at home. For each their own, I guess. :)
When I last tried KDE, the above drove me nuts. I encountered a function key combination not working in my app (Neverwinter Nights for Linux in this case). I spent -hours- trying to debug the application and searching for application specific solutions. Finally I figured out that the OS was trying to create a new desktop every time I hit the key combination. Then it was a long search online to figure out where and how KDE configured desktop shortcuts - because there wasn't anything intuitive to that in the menus. Then it was a long slog through different configuration lists, line by line, to find that ONE line in that whole mess to change that ONE setting.

Then I found the next combination that didn't work.

I was able to eventually de-map the OS from the function keys, but wow was it a pain in the ass. It certainly disinclined me from making KDE my default desktop for my installs to the 15 or so machines that I maintain for myself and family members - and took it off of my 'recommend' list to others.
 
Isnt that what superkey is for?

To me it sounds like people want different DEs for different things, and a full DE might just be in the way for some people.

In the same token of there are different ones for different people, its easy enough to change them.

Providing the customization that for example crunchbang provides is quite easy when its the same base (debian)

My personal preference is the least amount of visual stuff as possible/needed, and just hotkeys to switch between apps and do the things you would click to a meny to do elsewise.

Minimenu has some merit and is good for the specific usecase it serves, could try to build something out of that. Other than that its plenty of good stuff to chose from (XFCE, openbox custom, LXDE, E17, etc) could do like now and have one standard and the others even more available than they are from repo.

I definitely love the pndmanager, it has got things very right, and should continue in that direction.
 
Will need to be a community effort like the current implementation on pandora
Cyanogenmod is taking a business approach to their releases: you can now pay them to build and maintain an Android release for your system. This may be something worth looking into. It'll probably turn out to cost far more than it'd actually be worth but it doesn't hurt to investigate.
Do they have a posted pricing structure? Did some googling around but couldn't find anything. Hopefully it wont be too expensive that way we could potentially do it. Maybe like a poll "would you be wiling to add X more dollars to the sale cost of the Pandora to allow it to have official Cyanogenmod support"
 
On the current Pandora we already have MiniMenu and XFCE by default, and others (OpenBox, IceWM) via simple installers on the repo. I see no reason why we have to commit to one single window manager / desktop environment / GUI on the Pandora 2. We can still have MiniMenu and XFCE, and in addition to that also OpenBox, Gnome and KDE. All with various skins and themes and so on.

De gustibus non disputandum est, so there is no need to force something on everyone. That too is something that distinguishes us from polished but barely customizable software like iOS.
 
The default should be something so familiar to any party that they can change it for their favourite one.

XFCE is probably that, it also is familiar to pandora users, and it worked fine there.
 
If you go with debian, please don't use the new gnome... Or KDE...

 Have you seen the package manager on KDE debian vs the one XFCE?

Command line only was the fastest, until compter hardware became so fast that the Xenviroment with icons that link to command line scripts could have more operations avialabe to the user with faster execution then typing commands, for general use. At least with a lightweight desktop manager, when a huge crappy environment eats up all the resources it's not worth it.

Most of the time I just use the Pandora mini menu

Debian moves things around sometimes? I recently switched to Slackware because I was reading they like to stick to standards and only change things when needed, so things work more often. I havent been using it long enough to be sure that is true yet though.

I really like the package manager that comes with Debian XFCE, if configured with a source http://pandora.example.repothing  I bet that would be really useful. It looks like with slack you would have to pick a route for package management, there method is a http link that has a database list and uses tar files right? If your not planing on using debians package manager and using your own kinda like the pandora does now then would it be better to consider slack? I havent tried Arch or Gentoo yet I hear most people that get into them like them as well. In the end what is going to support the new pandora hardware/software the best will have a friendly environment for people to compile their own stuff for with the fewest issues and fastest speeds?

I started on Ubuntu and was trying to speed it up, so I was trying diff desktop environments. Thats when I read that ubuntu with XFCE was fast but Debian with XFCE was much faster, I bet reasons like that is why Debian pulls a lot of the popularity right now "from the Ubuntu". But were are they going to go when they want something better then Debian, is there such a thing? If so why? :lol:
 
Last edited by a moderator:
On the current Pandora we already have MiniMenu and XFCE by default, and others (OpenBox, IceWM) via simple installers on the repo. I see no reason why we have to commit to one single window manager / desktop environment / GUI on the Pandora 2. We can still have MiniMenu and XFCE, and in addition to that also OpenBox, Gnome and KDE. All with various skins and themes and so on.

De gustibus non disputandum est, so there is no need to force something on everyone. That too is something that distinguishes us from polished but barely customizable software like iOS.
This :

Defaults are important, if you present a new user with a huge list of options they will be overwhelmed and not interested in going much further. It may be very easy to change but having a default interface that just works without intervention is crucial.
There will be nothing forced on the user, but good default are important for 2 reasons :

- Some user wont change the default because ... (your guess here)

- Having openbox installed caused someone a problem with lastest SZ upgrade. That might happen in the futur and the team cannot decently support every other DE/WM on the planet.
 
Using XFCE would be fine. It's fast, it has a light footprint - what's not to like?

Debian has been toying with making XFCE the default DE as Gnome has become so large that it's hard to fit on a single install CD. There may be other reasons at play.

See "Desktop Environments" in http://en.wikipedia.org/wiki/Debian#cite_ref-25

It looks like XFCE is the default Debian DE for next year?

http://www.phoronix.com/scan.php?page=news_item&px=MTUwNDE

So... I move that there be a DragonBox repository with Debian stable with augmentations to fit our hardware and/or needs and XFCE as the default DE. Does anyone second that?
 
Fun :D !!!

I'm sure they choose debian because of ED's choice !
 
Last edited by a moderator:
Back
Top