Active Topics

 



Notices


Reply
Thread Tools
Posts: 5 | Thanked: 18 times | Joined on Dec 2012 @ Finland, Jyväskylä
#11
I went by the list and my votes are included in the attachment. Dunno which would be the best way to share these votes? Some external service or manually editing files which seems bit involved?

Anyway here are few highlights and my comments regarding them:

1. adobe-flashplayer - PURGE - Do we really need this for anything?
2. docpurge - PURGE - Is this necessary?
3. Various games - PURGE - they can be included in separate metapackage (Games) like discussed earlier.
4. Mediaplayer - REMOVE - Installable later if the user needs it by separate metapackage (Multimedia/Media Playing). Dunno how the depends go so needs to be checked first. Do we have a .deb for this purpose?
5. Nokia Maps - Remove - This could be included in a metapackage (Maps & Navigation). Do we have a .deb for this purpose?

What do you think of the above? Was there something I missed or is there something that cannot be removed so "widely"?
Attached Files
File Type: gz package-vote.csv.gz (14.5 KB, 305 views)
 
Posts: 9 | Thanked: 20 times | Joined on Sep 2015
#12
Originally Posted by blank View Post
I went by the list and my votes are included in the attachment. Dunno which would be the best way to share these votes? Some external service or manually editing files which seems bit involved?

Anyway here are few highlights and my comments regarding them:

1. adobe-flashplayer - PURGE - Do we really need this for anything?
2. docpurge - PURGE - Is this necessary?
3. Various games - PURGE - they can be included in separate metapackage (Games) like discussed earlier.
4. Mediaplayer - REMOVE - Installable later if the user needs it by separate metapackage (Multimedia/Media Playing). Dunno how the depends go so needs to be checked first. Do we have a .deb for this purpose?
5. Nokia Maps - Remove - This could be included in a metapackage (Maps & Navigation). Do we have a .deb for this purpose?

What do you think of the above? Was there something I missed or is there something that cannot be removed so "widely"?

Your updates have been added to 1st post. I figure that's the easiest place for people to follow along.

I'm a big fan of removing stuff, and re-adding it to other meta-packages.
 
Posts: 2,130 | Thanked: 8,333 times | Joined on May 2010
#13
Originally Posted by stryngs View Post
PR1.3 -vs- PR1.3.1:
- Are there huge differences?
Yes, PR1.3.1 contains only security fixes for certifiate management. Specially blacklisting certificates and blacklist database of comodo CA certs...

Originally Posted by stryngs View Post
- Which one should we go with? Is 1.3.1 seriously tested and considered as stable or more stable than 1.3?
Of course PR1.3.1!
 

The Following 6 Users Say Thank You to pali For This Useful Post:
Posts: 9 | Thanked: 20 times | Joined on Sep 2015
#14
This is the part of the thread where I will bring up de-optification and movement towards a more "universal" linux style filesystem. Currently, the way I do things, I use a bindmount technique. After purging unwanted .debs and upgrading to the kernel that I use, I perform my bindmount tricks. Now, You might ask, why not do the bindmount tricks after a full upgrade? Because it WILL fill /, and that's not cool. The point is to free / and make it have the least amount of crap on it. Also, this is where a Universal Argument is going to take place. "Stryngs, your bindmount techniques, they're not FHS!" I'll touch on that argument, after I describe what I do.

I would love to have bindmounted the whole FS, but, I don't know the "guts and boot processes" of the n900 like some of you smarter folks; so, I chose directories which I figured "safe" to do, and went with it. Luck worked out in my favor and my n900 boots correctly. I've always wondered, what happens if we bindmount /etc, /bin, etc.. etc.. etc.. So the story goes, when it comes to boot, some stuff is going to have to be "visible" to the bootstrapping process (wrong word?), while I've managed to hack together a solution for my purposes, I don't know if the bindmount technique would allow the Operating System to work if I went 100% bindmounted. I'd love to hear it from some of the smarter folks, and let me know what's up. Okay, Enough blabbing, here we go:

mkdir -p /home/rootfs_bind/var/lib
cp -ar /usr /home/rootfs_bind
cp -ar /sbin /home/rootfs_bind
cp -ar /lib /home/rootfs_bind
cp -ar /root /home/rootfs_bind
cp -ar /var/lib/dpkg /home/rootfs_bind/var/lib

After copying over the files, I modify /etc/event.d/rcS-late with the following changes:
mount --rbind /home/rootfs_bind/usr /usr
mount --rbind /home/rootfs_bind/sbin /sbin
mount --rbind /home/rootfs_bind/lib /lib
mount --rbind /home/rootfs_bind/root /root
mount --rbind /home/rootfs_bind/var/lib/dpkg /var/lib/dpkg

Reboot and p00f! Now, with the combination of the above, and my naked pymaemo-optify concept, installing a .deb works as the author of the .deb had intended, the files, in the / of the .deb, they actually go WHERE they were intended to go, not some /opt voodoo black magic. Also, as a side benefit (An intended one I might add...) You can grab ANY armel or all based .deb, and simply dpkg -i it. No having to worry about, "Oh noes, is this going to fill /?" Now, I'm not hating on optification; I just think the concept can be done smarter.

Alright, I said there was going to be an argument, so let's discuss it. FHS, also know as the Filesystem Hierarchy Standard. Standards, that what this whole concept is anyways, so it's a darn fine point to talk about. I've heard in chat over the past couple days about moving /usr to eMMC. Also, as has been brought up, if a .deb was built AS IT SHOULD HAVE BEEN, it too will follow the FHS, and thus, / will never overflow. So... The FHS argument trumps my bindmount technique 100%. The problem? I've yet to find a written and documented solution. Folks speak of it, but, in this instance, we need pixels on screens to form a coherent set of processes that We, the Community, can follow; otherwise it's just some homebrew technique, and one of the many reasons I cry out for the Unification of our community. SO... if you are one of those who possess the knowledge of how to move /usr over to eMMC, safely and efficiently, PLEASE... respond to this and layout the steps, from start to finish.

Lastly for this topic, there exists in my mind, some concerns with what I currently use. I'm not a kernel developer, I'm a hacker; I go with what I know and what I'm willing to try; however, the n900 can be delicate. As well, it's old and no longer in production; if I flash flash flash flash flash... Eventually, I might wear out my hardware, and then I no longer have my n900... Yes, I can buy another one, but why experiment if we don't have to. So here is my question; specifically I direct this question towards Pali. Based on what I've done, with my bindmount hack, How does this affect when you next release a new kernel? Since, at some point in the boot process, I'm guessing that /home/rootfs_bind/usr is NOT /usr, and /usr is really /usr, then the changes and updates, that have occured since original bindmount inception won't show during the bootprocess, at least not until rcS-late kicks in and mounts things. In other words, based upon what I've done, do I need to, in order to "properly and safely" upgrade the kernel, unmount my bindmounts, perform the kernel upgrades, copy the appropriate NEW files to their bindmount location and then re-bindmount?

Okay, hopefully I've confused everybody at this point. Heck, I confuse myself thinking about bindmounting sometimes. So.... Thoughts?
 

The Following 2 Users Say Thank You to stryngs For This Useful Post:
Posts: 9 | Thanked: 20 times | Joined on Sep 2015
#15
Originally Posted by blank View Post
I went by the list and my votes are included in the attachment. Dunno which would be the best way to share these votes? Some external service or manually editing files which seems bit involved?

Anyway here are few highlights and my comments regarding them:

1. adobe-flashplayer - PURGE - Do we really need this for anything?
2. docpurge - PURGE - Is this necessary?
3. Various games - PURGE - they can be included in separate metapackage (Games) like discussed earlier.
4. Mediaplayer - REMOVE - Installable later if the user needs it by separate metapackage (Multimedia/Media Playing). Dunno how the depends go so needs to be checked first. Do we have a .deb for this purpose?
5. Nokia Maps - Remove - This could be included in a metapackage (Maps & Navigation). Do we have a .deb for this purpose?

What do you think of the above? Was there something I missed or is there something that cannot be removed so "widely"?

p.s. When I update the CSV next, I will respond to your additions and such. I like them!
 
Posts: 482 | Thanked: 607 times | Joined on Sep 2010 @ Mbabane
#16
someone is saying to remove Nokia Maps? Gawd!
 
Posts: 1,371 | Thanked: 1,585 times | Joined on Jun 2010 @ Göteborg, Sweden
#17
Originally Posted by sicelo View Post
someone is saying to remove Nokia Maps? Gawd!
yes, from the base-install. So, a lean 'n mean, more standard Linux minimal install, with meta-packages for different areas of function, such as "Navigation".
 
pichlo's Avatar
Community Council | Posts: 4,681 | Thanked: 13,723 times | Joined on Sep 2012 @ UK
#18
I tried removing Nokia Maps in the past. There were no surprising dependencies so it went pretty well. The only problem was that removing Maps did not remove the Contacts integration so tapping on an address in Contacts still tried to open Maps on that address. I suspect removing Nokia Maps properly may involve more effort than anyone is prepared to invest.
 

The Following User Says Thank You to pichlo For This Useful Post:
endsormeans's Avatar
Posts: 1,871 | Thanked: 4,195 times | Joined on Feb 2013 @ Supa Natural Vancouver Island
#19
Agreed pichlo...
there will be some ugly spots I'm sure.
On the whole the idea of what the op proposes is sound and sane.
Having meta-packages somewhat similar to say [roughly] Bodhi ...
works well for it...
may work very well for us.
a single streamlining...
easy to implement and use..
universal one-stop shop does make sense ...
especially now with all the flavours...
and the need to be canny about what you are doing and how to do it.
I think cutting the Nokian [Gordian] knot is a good idea.
But as pichlo does sanely mention...
some things it might be better to just leave alone [ie- maps] and work around them [no harm in it] ...
making the work on this more ...um...expedient.. time-wise in effort...
to bring this to the community in a timely fashion.
__________________
Lurker since 2007, Member since 2013, Certifiable since 1972
Owner of : 1-n770 (in retirement),
3-n800's,
3-n810's,
5-n900's
-3 flawless
-1 loose usb (i don't muck with it & stress it , considering selling it, another can fix the loose usb)
-1 no telephony (perfect for permanent set-up as mini-pc with one of my monitors)
half a neo900 pre- "bought"....due for production any day now.


PIMP MY N8X0
Everything you need tightly explained in layman's terms ..in an easy to understand format.. and a video walkthrough to boot.
http://talk.maemo.org/showthread.php?t=94294
THE LOST GRONMAYER CATALOGS
http://talk.maemo.org/showthread.php...ight=gronmayer
N8X0 VIDEO ENCODING THE EASY WAY
http://talk.maemo.org/showthread.php...ght=mediacoder
242gb ON N800
http://talk.maemo.org/showthread.php?t=90634

THE PAIN-FREE MAEMO DEVELOPMENT LIVE DISTRO-ISO FOR THE NOOB TO THE PRO
http://talk.maemo.org/showthread.php?t=95567

AFFORDABLE MASS PRODUCTION FOR MAEMO PARTS
http://talk.maemo.org/showthread.php?t=93325
 

The Following 2 Users Say Thank You to endsormeans For This Useful Post:
panjgoori's Avatar
Posts: 1,200 | Thanked: 1,200 times | Joined on Aug 2011 @ Balochistan
#20
anyone have link for PR 1.3.1 firmware ?? i want to download it.
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 18:40.