Will We Get An Equivalent To The Standard Linux "shift+Delete"

[God Ginrai]

^ Stupid question, but did you make sure to make prm.sh executable?

^ Stupid Answer, no I didn't. <.< Thanks. I just hacked it up in mousepad and forgot that that was something I had to do manually. Works great now. ^_^

-God Ginrai

 

[MonkeyChops]

thanks mindlord. the scrip works beautifully. where can I learn more about the script language you used for that?

 

[mindlord]

thanks mindlord. the scrip works beautifully. where can I learn more about the script language you used for that?

This is Bash scripting, it is the Linux equivalent of a .bat file from Window and DOS. You will find the even the GUI tools you might use in Linux also have comprehensive command line options as well. Ready to be abused by a Bash script.

Zenity is actually just a X program designed to pop up dialogs, menus, and lists for users to interact with a Bash script in a graphical way. EvilDragon has used bash scripts and Zenity to create all of the configuration tools that you use to configure the Pandora. You can check them out yourself by looking in: /usr/pandora/scripts right click the scripts and open them in mousepad.

 

[NeonFuz]

Just wondering, why is everyone so concerned about writing to nand?

 

[kuru]

Just wondering, why is everyone so concerned about writing to nand?

As writing to flash memory wears it out over time, people are careful for the incoming 340+ years they'll be using their pandora and hence do everything to preserve their NAND.

 

[verm71]

Using the r option in rm -rf concerns me a bit. If you have a duplicate file in a subfolder, won't it get deleted too? If I've accidentally made a copy of a file from a folder into the root of my SD (or made a temporary copy to test with), if I use this option to delete it, the one in any and every subfolder will also be deleted.

I don't like surprises like this.

 

[mindlord]

The 'r' option doesn't behave like you describe, it will only recurse into a directory you give it. If you only give it the name of a file it won't go off looking for more files with the same name to delete.

Linux tends to avoid "undefined behaviors" such as that.

 

[WizardStan]

Just wondering, why is everyone so concerned about writing to nand?

1) There's very limited space on the NAND and you don't want to risk filling it up. It would suck if, a few months down the road, you can't apply awesome-patch-with-cool-stuff to the firmware because your savegames are in the way, yes? And sometimes you don't even know what stuff is going where, so it's difficult to clean without a full reflash, which brings us to ...
2) In the event of NAND file corruption, your only option is a reflash that will wipe out everything. If you're constantly writing to NAND, you increase the chance of corruption, and the risk that any files that you have saved there being lost when you inevitably have to reflash the firmware. Reflashing may also be part of a major upgrade: hotfixes work for now with this version, but if the next version involves new kernel, new drivers, a lot of new stuff to replace the old, it may be easier to just reflash as how most other consoles perform upgrades.
Some people also (or exclusively) believe that it wears out the NAND. Sometimes I like to encourage this belief only because it's easier to understand than the first two.

 

[NeonFuz]

Ok, i have one more question, is the home directory stored on nand?

 

[Pleng]

Yes

 

[WizardStan]

Ok, i have one more question, is the home directory stored on nand?

by default, yes, but many PNDs have already been setup that their HOME variable is put on the SD card before running the application. So the real answer is "it depends".

 

[verm71]

EvilDragon once said that the home directory is indeed on the NAND arguing that without an SD card, one would otherwise be unable to save settings.

While I understand this point of view, I can imagine the benefit of having the home dir on SD also. SD cards aren't that hard to come by, so running a Pandora in "read-only" mode until you get an SD card doesn't seem like such an inconvenient to me. Also, each user could have their own personal SD card with their directory on it. Or when you want to start fresh due to massive .file and .directory overload over time, you could just delete the folder off the SD card and let the pandora re-create it next time you log in.

Just thoughts.

 

[God Ginrai]

EvilDragon once said that the home directory is indeed on the NAND arguing that without an SD card, one would otherwise be unable to save settings.

While I understand this point of view, I can imagine the benefit of having the home dir on SD also. SD cards aren't that hard to come by, so running a Pandora in "read-only" mode until you get an SD card doesn't seem like such an inconvenient to me. Also, each user could have their own personal SD card with their directory on it. Or when you want to start fresh due to massive .file and .directory overload over time, you could just delete the folder off the SD card and let the pandora re-create it next time you log in.

Just thoughts.

I think it's more about the specific settings for the wm, etc. Not really settings for the browsers as much. I wouldn't want my wm reset every time I don't have an SD in.

-God Ginrai

 

[mindlord]

I agree with Sverm.

The vast majority of users are going to have at least one SD card in their Pandora, and most likely at least one card that is always inserted with applications that are essential to them. Using a Pandora without any SD cards is just a bad idea in general, IMHO. I see no reason not to make /home/[username] read-only and make a writable copy when a new SD card is inserted into the first SD Slot. A script could ask the user if it wants the SD card in slot one prepped to be the home folder, and go ahead and set up the /pandora/(apps/menu/desktop) folders for them while it's at it. Once the card is set up nicely the script flags it. so as to not prompt the user again. A user could conceivably have different desktop setups for different modes of work or play, just by inserting a different card into slot one.

I think it's an elegant solution to the NAND home issues, and makes the task of making sure a PND doesn't write to the NAND home out of the hands of developers and into the Operating System space. I could've released Remmina days sooner if I hadn't had to spend time hacking and testing it not to use /home... Just sayin'.

 

[Pleng]

I certainly never want to be in the position where one SD always HAS to be inserted (presumably in the same SD slot). I'm often ejecting SDs to download applications onto them with my laptop (much faster wifi) and as time goes on I imagine I'll be augmenting my current SDs with a couple of 32Gig cards. My 16 and 8 gig cards will then be used for films and music. Again I don't want to have to keep an SD card in place.

Besides, you already have the option of having HOME on an SD card; just BOOT from an SD card and HOME will be on that card. Don't impose your lifestyle choices on the rest of us though!!!

 

[WizardStan]

Besides, you already have the option of having HOME on an SD card; just BOOT from an SD card and HOME will be on that card. Don't impose your lifestyle choices on the rest of us though!!!

If you want home to be on an SD card, put "HOME=/media/mmblk1p1/home" (that's probably not quite right, but whatever) in your login script. Since it's a script, you can make it more intelligent, looking at both sides to see if it's there, maybe do a union mount against the NAND home directory so it writes to SD when one is inserted but to NAND when you remove it.
Actually thinking of it now (don't let me forget!) it may be possible to hack something into libpnd that will automatically mount a "home" directory on an SD card on insert and unmount it on removal. I'll have to think about it, maybe I'll experiment when I get my Pandora.

 

[mindlord]

I certainly never want to be in the position where one SD always HAS to be inserted (presumably in the same SD slot). I'm often ejecting SDs to download applications onto them with my laptop (much faster wifi) and as time goes on I imagine I'll be augmenting my current SDs with a couple of 32Gig cards. My 16 and 8 gig cards will then be used for films and music. Again I don't want to have to keep an SD card in place.

I never said you have to keep an SD card in place. I'm just suggesting that the default behavior should be that if no card is installed you can monkey around with your system all you want, and everything gets set back to default if you reboot. It's not that terrible. It protects your investment. It's good from a developer's standpoint because they don't have to worry as much about writing to home and it significantly reduces the time needed to port a large number of useful applications.

I know Skeezix once said that the developer can just "export $HOME" to somewhere else. Unfortunately for us, Gnome applications most often use g_get_home_dir() to locate home, and it will use the REAL home. I guess it's a security thing. I don't know, but that function bypasses the "export" trick. So instead of a simple grab the source and recompile for most of the applications in the Angstrom Repo. Devs will have to sniff out these g_get_home_dir() calls and check to make sure it's safe to replace them with g_get_current_dir() in addition to doing the export $home trick. It's not ideal, and eventually porters will care less about writing stuff to /home/[username] and things will get increasingly messy for the user. In the case if Remmina, even though I wanted to make the program never touch NAND, I couldn't because it looks for /home/[username]/.ssh which is managed outside of Remmina by the already installed SSH client. I couldn't help but write to your NAND. This is also not ideal.

Besides, you already have the option of having HOME on an SD card; just BOOT from an SD card and HOME will be on that card. Don't impose your lifestyle choices on the rest of us though!!!

Right! Sinoth's tarball works pretty good, but it has a few small issues for me, and it's not an official solution. Setting up a card to boot from is no picnic, especially for Windows users who can't easily format a card to EXT2 or extract the files with permissions intact. But I still opt to this. However, it's not really about lifestyle choice. It's about what's good for everyone in the long-term. Your Pandora would still perfectly usable without an SD card, and there's probably no reason why /home/[username] protection couldn't be toggled on and off so people could choose. What I'm saying is, it should be an EASY option for end users to take. They shouldn't have to jump through hoops to protect what should be protected in the first place.

In a perfect world, no program, except for firmware updates, should ever write-back to the NAND, unless absolutely neccesary. As long as home is on the NAND, everything you do is touching NAND. Open a terminal, .bash_history is getting written to every time you type a command. Using Evolution to check your mail? Guess where that's getting downloaded to? Using Fennec, Firefox, Midori, Arora? Guess where all that browsing history is getting written to? Open a PND that wasn't groomed to be NAND friendly, all that crap goes into your home folder, out of sight - out of mind. It's not in the /pandora/appdata/[pnd_id] folder where you expect it. It just took a whiz on your NAND for no good reason. The NAND is very limited on space and with each patch that space is only getting tighter. It's only a matter of time before this becomes a real problem for some people.

@WizardStan, while that is a "servicable" solution it:
1) is only good for people who are aware that this is a problem with the current setup to begin with
2) is only good for people brave enough to make those changes on their own
3) doesn't alleviate the burden of fixing the g_get_home_dir() issues in Gnome applications from the devs.

I really hope that the OP Team recognizes this as a very real problem for end users and developers alike, and doesn't continue to look at it as a matter of convenience.

 

[Pleng]

Actually thinking of it now (don't let me forget!) it may be possible to hack something into libpnd that will automatically mount a "home" directory on an SD card on insert and unmount it on removal. I'll have to think about it, maybe I'll experiment when I get my Pandora.

That sounds like a terrible idea! That means each SD would have its own home directory. And the Home directory would always be set to the last card inserted. You could end up with your data and config spread over multiple cards.

 

[Pleng]

I never said you have to keep an SD card in place. I'm just suggesting that the default behavior should be that if no card is installed you can monkey around with your system all you want, and everything gets set back to default if you reboot.

And if I take out my SD card which has HOME on it so I can watch a film from another SD card, what happens? I loose all my configs and over rides? HOME gets mounted to the new SD card? And any changes I make in the mean time get applied to my new card?

It's just a bad idea to have this behavior as default. It's going to confuse users.

It's not that terrible. It protects your investment. It's good from a developer's standpoint because they don't have to worry as much about writing to home and it significantly reduces the time needed to port a large number of useful applications.

I *want* developers to worry about writing to home. I don't WANT developers using HOME unless absolutely necessary. I expect my app's data to be kept in appdata, so I know where it is.

Granted there are some apps which are writing to HOME at the moment, quick dirty ports. Ideally I'd like to see uploads to the appstore only being approved when they've proven to NOT write to the home directory. Any thing you get from elsewhere is at your own risk, but appstore apps should be guaranteed HOME-friendly.

Clearly this isn't happening at the moment and I guess the team don't have the resources to implement it either.

 

[WizardStan]

That sounds like a terrible idea! That means each SD would have its own home directory. And the Home directory would always be set to the last card inserted. You could end up with your data and config spread over multiple cards.

Slow down now, you're under thinking this, tossing out the idea because one implementation that you just came up with on the spot may not be ideal.
You want an SD card to be your "home", you put a "/home" directory on that SD card which is then automatically unioned regardless of which slot it's put in. Remove the SD card, and either writes to home fail, or it falls back on the NAND. It still means that stuff can fail, or operate differently if you don't have your home SD card in, but it simply highlights the need to make as few programs write to NAND as possible.
If that doesn't work, we can brainstorm to find the solution that does work for you. Don't say an idea is terrible because you failed to get it right on the first try. If everyone did the same, we wouldn't have anything.