Jump to content

sarah31

Members
  • Posts

    217
  • Joined

  • Last visited

Everything posted by sarah31

  1. I would do CLI, then hit xwindows. don't bother with ncurses unless there is a demand for it. or unless you want to, that is-but personally I'd look at getting it working on the CLI (unless of course you're going to make use of already existing programs and just create a frontend, then you can jump it and go to GUI) then work on the GUI, ncurses as an afterthought as most people will prefer the GUI/XWindows. again, i must disagree. the more the better. start off with one good one, and then incorporate as many others as you can. re ncurses .... the reason i would have it as an interface option because it gives you basic gui that can be used in console should someone be working in console. user intrerfaces are preferred by many folks and excluding a potential gui interface in console is limiting features and users. just mho tho' re p2p ... i don't like any of them really but most of all i dislike gnutella as it is a very slow and undependable p2p server. giFT with all three plugins would be a good choice but many folks don't like the giFT controls. they are not as feature rich as gnutella and others. in general i think building a whole new media player would give you the most freedom instead of just scripting a gui interface over existing apps. of course this is likely not desireable if this is only going to be a part time project. media players are hard projects because you have to have a happy medium. you would have to sacrifice ALOT of your desired goals to be able to accomodate the most users.
  2. you could also do the less than lazy means of burning audio files from oggs buy converting them with oggdec to wavs then use cdecord to burn the files. nice thing about this is that you can even do this outside of X.
  3. several reasons: 1. prohibitative cost (free to charge it that's for sure) nearly $100 cdn is alot to pay for an installer and s gui tool that is not really very helpful past installation and setup. 2. they create dependence on the developers and not on the user. you can learn some linux stuff but only if you have problems. while many people go well it is good that someone is taking the effort out of linux what do those people say when a user has trouble and they have little clue as to how to fix the problem becuase the gui/cli tool hides the underpinnings of linux away. this dependence costs you nearly $200 a year or more cdn. 3. the developers make ALOT of money of of the user beyond the mere cost of the distro. the mailing list and forum are the main means of a user getting answers and tal and jon rarely contribute on this aspect. while they do get emails the majority of people use the mail list and forum because tal and jon are sometimes extremely slow in providing their up and running service. their help is not always useful (like the mail list and the forum). 4. the mixing of unstable, testing, and experimental trees makes it very difficult to upgrade---in the end many people rely on spending up to $100 for many major upgrades. despite tal and jon's use of all these trees they and the community as a whole try very hard to discourage users from using these repositories. they constantly spin tales of disaster. while problem can occur using both testing and unstable (and experimental trees) the problems are usually minor and are fixed quickly it is very very rare to have a disasterous results while using these trees. one just has to know how they can prevent problems (ie using synaptic which prevents alot of problems beforehand) 5. not having a gimped version for free download. i will spend money on linux and open source software but only if i can try it out first to see if it will work (everyone has probably had troubles with some distro like i did with mandrake 8.0 series). just imagine how you would feel if you spent $100 on software and it didn't work and then you had to go through the bother of getting your money back? or what if you spent the dough and found that libranet was completely not in your tastes? again you have to track down tal and jon and return the product then get reimbersed. 6. the community is very close minded and allows alot of abuse of people who don't swim with the packa and praise tal and jon and linux in general. they have no problem flaming you and ostricising you and even flaming real help you give. god forbid you have an independent mind that you are willing to express. 7. they leach off of others hard work and get the money and credit for it. i would like to see just what tal and jon have given back to the debian community as a whole (and don't give me that crap that they bring users to debian, if one can read one can install debian) and so forth. myself and several other people consider libranet to be the MS of linux. money first then help...if they feel like it. as for user requests you will have to pay for any additions (even if you just bought the previous version just a few weeks before)
  4. maybe the package that file is in is just readline not libreadline.
  5. mplayer...feh don't like it so skinning it is pointless besides i am sure th mplayer team has plenty of people contributing code for them already and it still has not improved it imho. and there already is good cross-platform ability for it to ....well to bsd and macosX. aac and mpc should be options ripper aspect would need to be VERY configurable most gui apps are not imho convert from mp3 to ogg for example? bad idea converting lossy to lossy is just not very desirable to many folks. well with itunes you can do this though it does not handle video (actually i like having separate video and audio applications---even in windows) well first and formost it should work on the cli, then ncurses, then xwindows hmm a multimedia player that does not handle multimedia right off??? :P similarily you should pole to see what p2p clients to incorporate.
  6. au contrare. linux would be very very easy prey if MS through a full head on campaign.
  7. libranet is evil and not just because the developers and community shunned me.
  8. you don't have the necessary depends likely to build either or the paths for the required headers. it is hard to tell from your errors though
  9. thats one of the points it allows you to run several different kernels or configs. this allows you to test stuff without forking up your main box.
  10. one of the arch linux developers runs it. i think he even made a package for it.
  11. just so you know if you keep to valid html your pages should display in ANY browser properly. I find though that, of course, IE is the hardest to please because it is so bloody forgiving of terrible code.
  12. well..iam not familiar with that mail reader but you maybe able to use procmail with it which can be used to sort your mail.
  13. there is ample information/guides on the w3c site as well as validators, etc. w3c homepage
  14. i don't dislike red hat i just don't use it. when i stopped using mandrake two years ago i vowed i would never use a rpm based distro again (not because of dependencies but because they are just not very good/smart packages). i could not care less what red hat, mandrake, or whatever distro does. i do respect red hat for being the distro for so many years that was the main go getter for linux in the business world. the linux community owes red hat their respect at the least imho.
  15. well it *may* give you slightly better performance but ultimately it gives you the control over where moz-firebird installs to ( i recommend /opt) edit as for dependencies of thos other apps: search freshmeat or the homepage of the apps it should be clarified there.
  16. yes they work hard as do many other developers in the programming and distro development world. as for new kernel features i would not bother with changelogs read one of the many articles out there. i do know devfs is being "replaced". alsa will be native in the kernel. usb is perporeted to be improved as is firewire support.
  17. actually you can build moz-firebird from source. if you so desire. the dependencies should be the same as moz.
  18. well unfortunately at this very moment i don't have time to give you any solid links. i am pretty sure that the documentation on the lfs site has some stuff on installing over a lfs base. ok i understand your reason for choosing RPM as a packaging. I personally would choose the package management system that is the easiest to work with and allows for easy manipulation of the setup parameters. while RPMs are common just choosing RPM may defeat your purposes for optimizing your sytem as if you just have the baseoptimized but do not optimize the package to be installed on that base may not mean the best performance of the installed programs which cannot achieve the same performance since they will be built for lesser processors (i386 to i586). i have not seen many rpms optimized with i686 flags. i will endeavor to find you some links if there is nothing on the lfs site for inits and package managemnt. but it will be much later today. PS i am not trying to discourage you from using RPM just making sure you consider some things you may not have thought of before.
  19. well one thing you may want to look at then is possibly using one of the other packaging formats (deb, portage, slackware, arch). because in my opinion they all are much easier to manage than rpms. while RPMs have finally gotten some better managers with dependency handling they were really not designed to be used in a "smart" package managment system. another thing with using another packaging system is that you can also potentially have a simpler file hierarchy. RPMs and debs tend to be rather messy in their placement. with your own, and much simpler, init scripts you can also avoid the mess of some distros tendency to run daemons as other 'users'. take a look at a debian user who is using just a few daemons and they are bound to have several "users" and a much heavier load average because of it.
  20. um...well you will still need to compile to make the executable binaries that go in the rpm package :roll:
  21. i suggest having them included as modules. some stuff you obviously have no choice on but generally everything you can include as a module you should. it allows for more flexibility (say if you should change your ethernet card or some other hardware). as for better x support and if you have a nvidia card i suggest making the agpart support stuff modules and not building them in. this will allow you to add lines to your xconfig file that will "turn on" the nvidia agp stuff (which is supposed to be better).
  22. what does ifconfig -a show you? it sounds as though your module is not loading right (or at all).
  23. i don't see a way around it unless you install gcc 2.xx.x. (that is have both 2 and three running on your system). perhaps if you let us know which driver you are talking about someone may be able to give you a url to the actual source of the driver. (for example the speedtouch modem source does exist out there).
×
×
  • Create New...