Active Topics
-
Full linux distros on Sailfish OS (255)
to SailfishOS by edp17 - 37 mins ago -
Sailfish OS on Sony Xperia X Compact (community build) (211)
to SailfishOS by monkeyisland - 2 hrs, 3 mins ago -
TLS 1.2 for N9 is ready (21)
to MeeGo / Harmattan by shakolan - 1 day, 1 hr ago -
Pinephone and Pinephone Pro on Leste vs Mobian (2)
to Maemo 7 / Leste by biketool - 1 day, 2 hrs ago -
Facebook chat on Nokia N9 - back to life :) (41)
to MeeGo / Harmattan by shakolan - 4 days, 20 hrs ago -
Any chance to get back mirror.thecust.net ? (3)
to MeeGo / Harmattan by dredlok706 - 4 days, 21 hrs ago - more...
|
2010-10-12
, 09:59
|
|
Posts: 842 |
Thanked: 1,197 times |
Joined on May 2010
|
#42
|
Originally Posted by benlau
It's called a PPA. You can usually find them for whatever package you want, and all it is is a small repo for whatever package or set of packages you want.
However, it has its disadvantage , you can not enjoy the newest software , you need to wait until the package manager is free to pack the software for you. For example , Firefox , you may need to wait for few days to weeks for newest version.
Want the absolute latest Firefox package? https://launchpad.net/~ubuntu-mozill...y/+archive/ppa <- Just use that. You'll have up-to-the-day updates, but the trade-off is that your using untested, nightly software.
If you are using a "stable" repo, like setup by default, then things are pre-tested for you, and generally won't screw up your system or have major bugs. On the other hand, running from devel, testing or nightly repositories can cause problems.
What a lot of people don't seem to get - You included - Is that there is generally a good *reason* for doing something one way. It may not seem the best to you, but you aren't developing an OS either. The people who generally decide these things have way more experience with such things than you or I - Trying to second-guess such knowledge isn't a good idea.
edit:
@TiagoTiago:
I think you are forgetting a lot. If it was as good as you say, you could take whatever DIR you installed to, copy it to a new Windows machine, and it would work. Unfortunately, it doesn't work that way with -most- programs. Some(that is, programs designed for Linux and ported to Windows), however will copy fine.
And that's not even taking into account draconian copy-protection measures like Photoshop frigging writing to your MBR!
Last edited by RobbieThe1st; 2010-10-12 at 10:02.
 |
|
2010-10-12
, 10:29
|
|
Posts: 135 |
Thanked: 375 times |
Joined on Mar 2010
@ Hong Kong
|
#43
|
Originally Posted by RobbieThe1st
I have my own PPA account , I offer package for my OSS software , and backport package , for example , Qt for Hardy. Although I am not a Debian developer , I have made Debian package for many years. I use Debian SID for my desktop , it is changed to Ubuntu few month ago. And my day time job is about embedded Linux product, that may include u-boot , kernel porting.
It's called a PPA. You can usually find them for whatever package you want, and all it is is a small repo for whatever package or set of packages you want.
Want the absolute latest Firefox package? https://launchpad.net/~ubuntu-mozill...y/+archive/ppa <- Just use that. You'll have up-to-the-day updates, but the trade-off is that your using untested, nightly software.
If you are using a "stable" repo, like setup by default, then things are pre-tested for you, and generally won't screw up your system or have major bugs. On the other hand, running from devel, testing or nightly repositories can cause problems.
What a lot of people don't seem to get - You included - Is that there is generally a good *reason* for doing something one way. It may not seem the best to you, but you aren't developing an OS either. The people who generally decide these things have way more experience with such things than you or I - Trying to second-guess such knowledge isn't a good idea.
yes , I am not developing OS , but I don't think I am a layman user of Linux. I just want to express my opinion toward the package system.
Moreover , I am not saying that package system is not good , but it is not prefect. An addition way of software installation is not a bad idea too.
I have a Mac book pro , it is used for my day time job. Their DMG is really a simple software installation method . However, Mac OS still have its own package system , mpkg . System software and library installation usually use this format. It just like deb / rpm , but the feature is much poor.
DMG is for application software installation ,and mpkg is for system tool . User normally won't need to deal with any dependency issue , installation just means to drop the file to Application folder. Why can't we consider this additional installation method? And restrict ourself to a single way? Just becoz we are not developing OS?
__________________
Qt Ambassador | Nokia Certified Qt Specialist
PenPen SketchBook |
FrontView - 0.2 is released! | DQuest
Status: Now working on GTD software
Qt Ambassador | Nokia Certified Qt Specialist
PenPen SketchBook |
FrontView - 0.2 is released! | DQuest
Status: Now working on GTD software
Last edited by benlau; 2010-10-12 at 10:34.
| The Following User Says Thank You to benlau For This Useful Post: | ||
|
|
2010-10-12
, 10:31
|
|
Posts: 1,522 |
Thanked: 392 times |
Joined on Jul 2010
@ São Paulo, Brazil
|
#44
|
If the package manager keeps track of where things are installed, any program that would need to know if a given program is installed and where would just check the place where the package manager stores that information.
Regarding DLLs in Windows, in the rare cases i need a program to use an specific DLL instead of the one present in PATH i just put a copy of the DLL in question in the same folder as the executable, and in several instances i've updated a DLL because of one program, and didn't even had to do any tricks to keep other programs working, the newer version of the DLL remained compatible (perhaps nowadays developers are more carefull when releasing newer version of their DLLs? Or perhaps i've just been lucky all these years...)
Many programs in Windows do offer the option of keeping it all in a single folder, for those that don't i can just install them inside Sandboxie on a pendrive or whatever.
Regardless of the OS, i consider it much more tidy to keep things that are only for a given program instead of being shared be under a single folder than spread all over; ideally configuration files would all have the same extension so if i ever needed to find them all it would be just a matter of running a search. If i even need to backup things from a program i often just copy the install folder, and then i transfer whatever files back if after a reinstall they aren't kept (even better when the program divides it's files in subfolders according to what they are about). Another nice thing with this approach is there is no risk of name conflicts, all programs can have their own "config.ini" without needing to prepend their own names and versions making filenames long and annoying to read.
Regarding DLLs in Windows, in the rare cases i need a program to use an specific DLL instead of the one present in PATH i just put a copy of the DLL in question in the same folder as the executable, and in several instances i've updated a DLL because of one program, and didn't even had to do any tricks to keep other programs working, the newer version of the DLL remained compatible (perhaps nowadays developers are more carefull when releasing newer version of their DLLs? Or perhaps i've just been lucky all these years...)
Many programs in Windows do offer the option of keeping it all in a single folder, for those that don't i can just install them inside Sandboxie on a pendrive or whatever.
Regardless of the OS, i consider it much more tidy to keep things that are only for a given program instead of being shared be under a single folder than spread all over; ideally configuration files would all have the same extension so if i ever needed to find them all it would be just a matter of running a search. If i even need to backup things from a program i often just copy the install folder, and then i transfer whatever files back if after a reinstall they aren't kept (even better when the program divides it's files in subfolders according to what they are about). Another nice thing with this approach is there is no risk of name conflicts, all programs can have their own "config.ini" without needing to prepend their own names and versions making filenames long and annoying to read.
__________________
NOKIA N900: IT'S OVER NINE THOUSAND
How to use HotspotShield in the N900
Google Voice from outside the US + Free international calls: LEARN HOW HERE!!!
NOKIA N900: IT'S OVER NINE THOUSAND
How to use HotspotShield in the N900
Google Voice from outside the US + Free international calls: LEARN HOW HERE!!!
|
|
2010-10-12
, 10:39
|
|
Posts: 842 |
Thanked: 1,197 times |
Joined on May 2010
|
#45
|
Well, it seems to me that the whole point of Linux packages is that everything is modular. You don't need to install all of, say, QT if you only need bits from one or two modules. Sure, it means that manually installing packages means installing dependencies as well, but the whole idea is to do it automaticly.
The advantage is you don't have much - if any - duplicated libraries or data. You have one copy, and its used by many things. This may not be very important on a Desktop or laptop where you have hundreds of GB to play with, but consider that on the N900 we only have 2.25GB -TOTAL- OS space, and the core sits in less than 256MB.
Also - ignoring dependency issues - on my Ubuntu desktop, there was a nice little DPKG-frontend that would let me double-click on a package and install it. No command-line, no nothing. It would even install dependencies, provided they were available.
Personally, I think deb packages are a great idea. Sure, there may be some issues repo-side; having people upgrade to the right versions etc... But those can be dealt with. And its better than Windows installation, for sure.
The advantage is you don't have much - if any - duplicated libraries or data. You have one copy, and its used by many things. This may not be very important on a Desktop or laptop where you have hundreds of GB to play with, but consider that on the N900 we only have 2.25GB -TOTAL- OS space, and the core sits in less than 256MB.
Also - ignoring dependency issues - on my Ubuntu desktop, there was a nice little DPKG-frontend that would let me double-click on a package and install it. No command-line, no nothing. It would even install dependencies, provided they were available.
Personally, I think deb packages are a great idea. Sure, there may be some issues repo-side; having people upgrade to the right versions etc... But those can be dealt with. And its better than Windows installation, for sure.
| The Following User Says Thank You to RobbieThe1st For This Useful Post: | ||
 |
|
2010-10-12
, 10:47
|
|
Posts: 1,389 |
Thanked: 1,857 times |
Joined on Feb 2010
@ Israel
|
#46
|
cause u don't have separete hard drives like in windows (c: d: e.g.) and u can make any folder as separete hdd, so it's pointless in linux. what's the point on having something in other folder and having extra files (symlinks) ?
|
|
2010-10-12
, 10:48
|
|
Posts: 1,522 |
Thanked: 392 times |
Joined on Jul 2010
@ São Paulo, Brazil
|
#47
|
If package makers do it wrong, shared libraries etc don't go where other programs expect to find them might endup duplicated, right? Same thing in Windows.
I like the dependencies stuff, checking if other programs are using stuff before uninstalling etc. But dumping all executables on one folder, all configuration files on another folder etc makes quite a mess, the other day i wasted a lot of time scrolling trying to find the executable for an specific program.....
IMO it makes much more sense to keep each thing in it's own folder, and if necessary add stuff to a list, symlink it or whatever to make other programs find it, or like i said, if the package manager is already keeping tabs of what is where, take advantage of that and read that data if you wanna know if a program is installed and where; relying on hardcoded paths is laziness...
I like the dependencies stuff, checking if other programs are using stuff before uninstalling etc. But dumping all executables on one folder, all configuration files on another folder etc makes quite a mess, the other day i wasted a lot of time scrolling trying to find the executable for an specific program.....
IMO it makes much more sense to keep each thing in it's own folder, and if necessary add stuff to a list, symlink it or whatever to make other programs find it, or like i said, if the package manager is already keeping tabs of what is where, take advantage of that and read that data if you wanna know if a program is installed and where; relying on hardcoded paths is laziness...
__________________
NOKIA N900: IT'S OVER NINE THOUSAND
How to use HotspotShield in the N900
Google Voice from outside the US + Free international calls: LEARN HOW HERE!!!
NOKIA N900: IT'S OVER NINE THOUSAND
How to use HotspotShield in the N900
Google Voice from outside the US + Free international calls: LEARN HOW HERE!!!
|
|
2010-10-12
, 10:50
|
|
Posts: 135 |
Thanked: 375 times |
Joined on Mar 2010
@ Hong Kong
|
#48
|
Robbie,
great, I have two common consensus with you. "Deb packages are a great idea!" and "And its better than Windows installation , for sure"
well , my point of view is not only on N900 , but also talk about desktop Linux (As the thread is also talking about Windows desktop) . You may ignore AppImage if you want to talk N900 only.
great, I have two common consensus with you. "Deb packages are a great idea!" and "And its better than Windows installation , for sure"
well , my point of view is not only on N900 , but also talk about desktop Linux (As the thread is also talking about Windows desktop) . You may ignore AppImage if you want to talk N900 only.
__________________
Qt Ambassador | Nokia Certified Qt Specialist
PenPen SketchBook |
FrontView - 0.2 is released! | DQuest
Status: Now working on GTD software
Qt Ambassador | Nokia Certified Qt Specialist
PenPen SketchBook |
FrontView - 0.2 is released! | DQuest
Status: Now working on GTD software
|
|
2010-10-12
, 10:50
|
|
Posts: 184 |
Thanked: 112 times |
Joined on May 2006
|
#49
|
Originally Posted by TiagoTiago
Dude (or -ette), you need to stick with windows, because that is what you apparently know alot about. There is no point in having a philosophical debate about the difference inherent in Linux and Windows. Obviously, you prefer Mr. Softy's filesystem solution...I prefer *nix filesystem. There are pros and cons to each....choose one that is right for you and don't expect your Linux phone to behave like a windows phone....caveat emptor.
If the package manager keeps track of where things are installed, any program that would need to know if a given program is installed and where would just check the place where the package manager stores that information.
Regarding DLLs in Windows, in the rare cases i need a program to use an specific DLL instead of the one present in PATH i just put a copy of the DLL in question in the same folder as the executable, and in several instances i've updated a DLL because of one program, and didn't even had to do any tricks to keep other programs working, the newer version of the DLL remained compatible (perhaps nowadays developers are more carefull when releasing newer version of their DLLs? Or perhaps i've just been lucky all these years...)
Many programs in Windows do offer the option of keeping it all in a single folder, for those that don't i can just install them inside Sandboxie on a pendrive or whatever.
Regardless of the OS, i consider it much more tidy to keep things that are only for a given program instead of being shared be under a single folder than spread all over; ideally configuration files would all have the same extension so if i ever needed to find them all it would be just a matter of running a search. If i even need to backup things from a program i often just copy the install folder, and then i transfer whatever files back if after a reinstall they aren't kept (even better when the program divides it's files in subfolders according to what they are about). Another nice thing with this approach is there is no risk of name conflicts, all programs can have their own "config.ini" without needing to prepend their own names and versions making filenames long and annoying to read.
 |
|
2010-10-12
, 10:50
|
|
Posts: 1,637 |
Thanked: 4,424 times |
Joined on Apr 2009
@ Germany
|
#50
|
Originally Posted by TiagoTiago
dpkg -L <packagename>
If the package manager keeps track of where things are installed, any program that would need to know if a given program is installed and where would just check the place where the package manager stores that information.
shows you what and where are the files from this packages.
Originally Posted by TiagoTiago
What I meant is, even if you can select an install directory, you can not
Regarding DLLs in Windows, in the rare cases i need a program to use an specific DLL instead of the one present in PATH i just put a copy of the DLL in question in the same folder as the executable, and in several instances i've updated a DLL because of one program, and didn't even had to do any tricks to keep other programs working, the newer version of the DLL remained compatible (perhaps nowadays developers are more carefull when releasing newer version of their DLLs? Or perhaps i've just been lucky all these years...)
be sure that no other files are installed somewhere else. Setting-/
configurationfiles, links for the programmenu, tempory application folders
are often stored in the windows or root directory and/or the users
directory.
__________________
my contributions:
Desktop Clock Widget|Calendar Home Widget|Lens Cover Reminder|ConnectNow|Scout|App Search Widget|ProfilesX|
Desktop-Switcher|SMS-Messageblocker
-Donate-
my contributions:
Desktop Clock Widget|Calendar Home Widget|Lens Cover Reminder|ConnectNow|Scout|App Search Widget|ProfilesX|
Desktop-Switcher|SMS-Messageblocker
-Donate-
| The Following User Says Thank You to nicolai For This Useful Post: | ||
http://www.engadget.com/2010/10/11/w...-launch-guide/