Jump to content

iphitus

Global Moderator
  • Posts

    3831
  • Joined

  • Last visited

Everything posted by iphitus

  1. This is going to take a long time, and even if this came in tommorow, many of our problems wouldnt be fixed, as the main issues now are: - driver maturity - userspace applications both of which are improving gradually with time. NetworkManager has been great for the gui heavy distros out there. James
  2. irssi for irc, gaim, on a different workspace for jabber,msn. I wish i could take that credit :) dwm, ion, wmii and those wm's have a helluva lot of popularity among Arch. James
  3. ok, let's see how defective this thread is ;) http://iphitus.loudas.com/images/190407.png functionality > form James
  4. if kget doesnt do multipart downloads or other fancy things, you may be able to recover the 2gb download using wget -c James
  5. it wouldnt be X, as the percentages you saw were CPU usage, not disk usage. The only hdd usage X deals with after startup is logfiles. I really doubt it's spitting things out every second, X tends to be pretty quiet. As said above, turn off beagle or adjust it's indexing options. And if your system has it, give us the output of 'pstree', which you can run in 'konsole'which should give us a reasonable idea of what's running and could be using the disk. James
  6. arch mailing lists are here: http://www.archlinux.org/mailman/listinfo/ James
  7. The question is, did they fix the bugs? I might well install this release :)
  8. On Arch, install from the latest ISO, update, enable the testing repository, then just use the computer :). If you see interesting or relevant new projects or improvements mentioned on the arch-dev-public mailing list, give them a try. It's a fairly low traffic list. And importantly, if you have problems with anything, file bugs, or contact the maintainer, and let them know you're willing to spend time testing things. I'm developing new network scripts for example, and will soon put out a call, looking for some testers, particularly wireless users, to use them on a daily basis, and report back to me with any problems/fixes/suggestions. On other distro's, the process would be similar, for mandriva, run cooker, file bugs. I'm sure, opensuse, fedora and other distros have similar processes available. And to clarify the above, developers love *good* testers. Those who can report whatever details or follow the problem up, as many just file a bug with no information, and never respond to requests for information, leaving a bug hanging. James
  9. Then become a tester. Developers honestly *love* testers, and you'll learn a helluva lot working through problems and trying to fix them collaboratively. More than just installing another distro. Give the latest arch linux release another shot, it's pretty sweet, and nowhere near as buggy as prior ones, we've been working hard to fix that, and we had some nasty changes in the past that were unavoidable. The new network scripts are rocketing along... and should be in testing sometime soon. They're simply awesome, better than any other distro's wireless setup. If I had the money, i'd pay you to help test for Arch.... but the lottery win is a long way away. Otherwise, BSD is awesome fun..... but the thing is, once you set them up, it 'just works' and becomes very boring :) -- Or at least, that's my experiences with Net, Open and FreeBSD. My ideal 'distro' is FreeBSD, with pacman+makepkg for packaging........ oohh yeah. That would rock sooo much. It's still on the drawing boards :) James
  10. the bugfixes will probably be available as updates anyway. And if you're running it, it's probably not critical, not all bugs effect everyone. James
  11. wait up a moment, how is drive 2 being 'shared'? If it's shared across a network using samba, then it's fine for it to be ext3 or any other linux filesystem. The windows clients do not write to the partition, they communicate with samba, and samba writes to the partition. The windows clients never see the real partition, they just need to speak SMB, the samba protocol, to tell samba what to do, and samba, running on the server does the work. James
  12. ntfs-3g just gives you access to your ntfs files from linux, it will work fine with rsync. You could just as easily use the stock linux ntfs module as well, as rsync only needs read-only access to the windows files. James
  13. Intel's listed too. As said above, the article is short on technical details.... so i wouldn't be getting too concerned yet.
  14. nvidia is listed too, so maybe it's intended for general adoption?
  15. Looks far more draconian than that even. They talk about restricting access to the *framebuffer* The framebuffer is where what is to be displayed on screen, is written. So not letting you have access to the framebuffer is about as draconian as it can get. You cannot read it, you cannot write to it. Only applications by the approved companies may. The article is skimpy on details and is devoid of technical knowledge, so i'm hesitant to jump to conclusions, but if the above comment is true, then linux simply would not be able to display X on the affected graphics cards, unless ATi release drivers that are "permitted" to display... James
  16. iphitus

    zSNES and SDL

    OLD THREAD ALERT! anyway, the first mistake in this thread is using an RPM from a website and NOT urpmi. Always use urpmi first is the moral of this thread. James
  17. Newer versions of ipw3945 are much better, and there's a brand new module, which will be merged, that is far better. As for intel hd audio, there's improvements and support added on every release of the kernel, so 95% of the intel hd audio boards out there *do* work fine. If yours continues to not work, it might well be a good idea to file a bug on the kernel bugzilla, rather than continually complaining. No brand in particular is any good at supporting linux, unless they say so explicitly. All brands either take an Intel or AMD attack, the intels will work on linux nearly every time, with minor bugs in some, and AMD's should work better now than they have. The minor bugs in them, are irrelevant to the vendor, and occur across different models by different vendors. Most consumer grade hardware out there is supported by linux, but it's just that some take more effort. James
  18. /me plugs his MS Natural Ergonomic Keyboard 4000. best. keyboard. ever.
  19. Well, ok technically, you're right, GCC/Glibc can be upgraded for smaller point releases without issue, though this update is not such. And yeah, he can recompile his whole system if he wants, but seeing as there's a shiny new versions of mandriva, it's be far quicker to upgrade wouldnt it? ;) James
  20. Welcome to the board :) It's not easily possible to update glibc, as all the things you have installed already need the glibc you have now, and will not work with the new one. If you force it, it will break your system. So, to update glibc, you need to update almost *every* package on the system. You're better off upgrading to a newer release if you need that application. James
  21. No, monolithic vs micro kernel is entirely different. microkernel has drivers split off into userland, and the drivers communicate with the very basic kernel via IPC of some sort. monolithic, like the linux kernel, is where it all runs as one big kernel within the address space. Modules are still 'monolithic' as they're just added into the kernel's operation. The important difference is how the microkernel is layed out, with drivers in userspace, whereas with a monolithic, they're all in kernel space. James
  22. or she knows where the magical mystery evidence is.
  23. Yes, and no. There's no *performance* hit in loading modules. The computer will just take longer at the loading modules stage of boot, but if you compile them all in, the computer just takes longer at the kernel initialisation early in the boot. There's only a second or two the difference, if any. Apart from that, unless you actually patch the kernel to be different, you won't see a difference between the new and the old kernel. Most people believe they see a difference, but that's usually placebo, or because the new booted system has more ram to play with and less running. James
  24. shouldnt be a big concern. If it's just a security or bugfix, then they often can be applied, and tested minimally before releasing. Whether it's kdecore or kopete, it doesnt matter. If it's a whole new major release, then it's usually not too difficult to just backport security fixes. James
  25. Give it a few days, they probably just updated to the branded packages to make sure theres no problems with those, and if there's no issues with this RC, then yes, release will happen. So if you find a bug, file it quick! James
×
×
  • Create New...