Slashdot Mirror

So far as I can tell he claims that it would be impossible to re-license it under an OSS license and allow Matthew Green to use the trademark.

probably true =- but why not just do what fedora did with "RealCrypt" - fork it and change the name?

In order for this not to happen again do the following:

Stop using Windows and MacOSX.
Download and install Fedora F16.
When installing, encrypt the harddrive with a really hard to break password.
Install pidgin and off the record like this: 'yum install pidgin pidgin-otr'
Generate keys and verify them before communicating.
Be _very_ careful if who you usually talks to changes their key, they might have been arrested.
Never ever communicate in the clear.

Using this strategy you will not be immune, rubber-hose-cryptanalysis with still defeat this. Also you can be tracked so your oppresive government can see that you communicate, they will just not be able to read what you are saying. And not using major OSes will keep you away from the most common exploits and trojans.

Also, try to use TOR, HTTPS-everywhere and other good tools.

References:
https://fedoraproject.org/
http://fr2.rpmfind.net//linux/RPM/fedora/16/x86_64/pidgin-otr-3.2.0-4.fc15.x86_64.html
http://www.cypherpunks.ca/otr/

Good luck.

But it only takes about 60 seconds with a web browser [tinyurl.com] to give you a very complete, concise answer

The first link in your Let-Me-google-that-for-you results points to:
this page

blah blah blah...
ote: to install applications from source code, you will need a C++ compiler (gcc++) installed. This is generally taken care of, but I've had enough queries about it that I've added this note to avoid getting more! You can use your distribution's install CDs to get the proper version of the compiler. Or, if you are using an RPM based distro, you can use a site like http://www.rpmfind.net/ to locate the correct RPM version for your system. (You will obviously not be able to use/rebuild a source RPM to get the compiler installed, as you need the compiler to build the final binary RPM!) On a Fedora system, you can do this command:

su - root
yum install gcc gcc-c++

Log in as root

Because we will be installing softwa...
blah..rpm -qa

in conjunction with grep to filter your results:

rpm -qa | grep -i apache
rpm -qa | grep -i httpd
rpm -qa | grep -i php
rpm -qa | grep -i mysql

while the first link from "wamp install" is:
this

1 Download the latest release of Wampserver 2
2 Optionally add as much Apache, PHP and MySQL releases as you want
3 Work with a development environment that reproduces exactly your production server

Seriously WTF... if even installing Open Source software is easier in Windows than in Linux... then I understand why people is reluctant to move to Linux. (e.g., where are the portableapps for Linux?, download-click-use)

I would agree that Firefly/Serenity ended up with some darned loyal fans. I'm sure Star Wars has *more total* loyal fans, but Firefly/Serenity probably has a higher percent. Heck, I got sucked into being a browncoat myself, to the point that I carved Firefly Jack-O-Lanterns and made the fortune-firefly package (official fedora packages here). The Jack-O-Lanters fared much better than last year's Donnie Darko one which, while it looked great, tried to burn my house to the ground.

In your situation, I would of tried using the RPM from Fedora Core 4 or such for FreeCIV.

As for binary compatability, I just grabbed the FreeCIV RPM for FC5 and installed it under Mandriva Linux (a entirely different distro). It's working fine too. *shock* *awe*

Binary compatabiltiy doesn't seem to be a issue here.

It's my personal opinion though that if you want to be able to run cutting edge new version apps, then maybe you should be using distros designed todo that.

Are you arguing that RPM doesn't have this? Here's a clue: dependencies can be any keyword, so "requires webserver" will be satisfied by any package that "provides webserver," such as apache or boa. Same thing for your other points.

Are you arguing that RPM doesn't have this? Here's a clue: dependencies can be any keyword, so "requires webserver" will be satisfied by any package that "provides webserver," such as apache or boa. Same thing for your other points.

Click here to get Quake 3.
ftp://fr2.rpmfind.net/linux/freshrpms/redhat/7.0/q uake3/quake3-1.17-1.i386.rpm

Visit http://rpmfind.net/linux/RPM/ to see what the parent meant. Surely, if you have been arround Linux for some time, you would know that though RedHat and SuSE use the same package format (RPM), packages prepared for SuSE will not necessarily install on RedHat and vice versa. Need more examples?

Then my biggest concern is the almighty compiling to install software,

Welcome aboard, you don't have to compile all the software. Only the bleeding edge stuff. Try out one of these sites:

rpmfind
rpmseek

Choose the rpm that matches your distrubution, download, install. If you use Kde/Gnome, click on the file and install.

Enjoy,

Ok. Video card. You can use the ATI fglrx driver.
Here are the SuSE 9.2 install instructions. Sadly, its not as easy as an NVIDIA card. But you will get hardware 3d and TV out.
http://suse.cbn.net.id/i386/supplementary/X/ATI/su se92/i386/fglrx/8.8.25/

Video capture. Supposedly, you can use the 'Gatos' capture project. This is designed for 2d acceleration, video capture, and several other ATI features. I've never played with it myself, since I've only owned standard radeons, never a AIW.
The site is here:
http://gatos.sourceforge.net/overview.php

But i've been browsing their mailing list, and it doesn't seem like the 9600 is supported. There is a LOT of work being done on it, though, and there are several devel list entries from the beginning of the month.

Sound&Modem, as you already know, will be a breeze.

Your gigabit ethernet card has drivers avaliable from the manufacturers website. This is here: http://www.marvell.com/drivers/driverDisplay.do?dI d=107&pId=10
I'm assuming you meant Yukon, not ukon.
This page here suggests that it is avaliable in the lastest 2.6 kernels (This is Gentoo, not SuSE)
http://64.233.167.104/search?q=cache:3PYpQxdJcwoJ: linuxforums.org/forum/ntopic31345.html+Yukon+SuSE+ 9.2&hl=en&start=16&client=firefox-a
This seems to suggest its in the default install:
http://rpmfind.net/linux/RPM/suse/9.2/i386/lib_mod ules_2.6.8-24.10-bigsmp_kernel_drivers_net_sk98lin _Tree.html
I'm not really sure, as I have little experience with Gigabit ethernet.

The broadcom wireles will present a moderate amount of difficulty, but it can be made to work, and if you are willing to spend a little money, it can be made to work easily. There are no native linux drivers, so you can either use ndiswrapper http://ndiswrapper.sourceforge.net/, which is an opensource project that allows you to use the Windows drivers, or you can use linuxant's Driverloader, avaliable at http://linuxant.com/

The bcm4306 is confirmed supported under both, but I know from experience that driverloader is extremely easy to use, but ndiswrapper is slightly more challenging (still not impossible, but requires editing some configuration files by hand). SuSE has been working on integrating Driverloader into the distribution, but it hasn't happened yet.

Yeah, the floppy, the 7-in-1 usb reader, the DVD drives, etc, will all work without any difficultly. If you intend to use a USB dvd burner in SuSE, you will need to "sudo chmod +u /usr/sbin/cdrdao & sudo chmod +u /usr/sbin/cdrecord" which is a minor security risk. SuSE, for some reason, has redesign those two to not run as root, but it doesn't work properly for USB writers. That simple chmod command will fix that, and then you will be able to burn CD/DVDs under SuSE.

Here, http://lists.suse.com/archive/suse-amd64/2005-Jan/ 0019.html Someone refers to using your motherboard, and it seems to work properly.

BTW: I've been checking the SuSE hardware database, and it seems to have started working, but it is by no means comprehensive. http://hardwaredb.suse.de/index.php?LANG=en_UK Once again

Umm, no. Debian controls their main repository, as does Red Hat. Debian has no control over the many alternative repositories listed at http://www.apt-get.org/, and Red Hat has no say about the contents of http://rpmfind.net/.

Any system that lets users can add unofficial package sources to their management system is subject to dependency hell. RPM-based systems happen to get the lion's share of bad publicity in this department, but any Debian user who experimented with the alternative KDE packages people were sending out before the official packages were available knows that it is every bit as susceptible as Red Hat.

Maybe the main difference is that darn near every program you've ever heard of is available from the official Debian sources, so there's almost never any need to use third-party sources. If Red Hat packaged everything under the sun, then their users would probably use those packages and there would be many fewer problems. I'm not suggesting that Red Hat do this, but I do believe that's the reason for their reputation.

A quick google search shows that there are also rpms available for download.
routeplanner-gnome-0.9-1.noarch RPM

... and the main sourceforge site is Project: RoutePlanner: Summary

Thanks for the tip! I've been passively looking for something like this for a while. I'm planning on downloading it and playing with it also.

For a Web app, a link checker can act as an automatic 'smoke test'. While link checkers do not substitute for unit tests and coverage matrices, they offer a nice trade-off as a low-cost, automatically-expanding tool that can uncover problems quickly.

Any link checker will do for well-linked 'public' pages which do not require a login. On linux, see checklinks for example.

With some additional code, a link checker can:

* log into a login-protected web app and carry the resulting cookie between queries
* spider from each of a list of start pages (ensuring each of these is hit, at minimum)
* parse resulting HTML for required common components (e.g. header/footer), as well as for human-readable error messages like the text "Cannot display ..."
* limit redundant visits to same 'state' with different parameters (requires a URL scheme with identifiable finite state)

For an example of a FOSS link checker with these features, see morebot.

Linux is binary compatible at the same level as windows is. You're comparing apples to oranges. You mentioned GIMP as one of the windows applications. How big was the installer you downloaded? Did you need to download two installers? I bet you did, and you got them from right here. That's the GIMP and the GTK libraries it requires. Here is an example of an RPM for GIMP on Linux. Notice that it has a lot less because Linux already have GTK installed. Those are the dependencies that break.

Open source software shares a lot of common libraries that users don't want multiple copies of lying around. Dependencies like this exist in windows too. For instance, look at programs written in Visual Basic that require the VBRun DLL libraries to be installed.

Swapping out kernels doesn't usually effect the programs sitting above the kernel. This is called "binary compatibility" and has existed in Windows and Linux for some time.

Sir, you are missing the point. Of course I found everything I needed in the end. A large number of the missing packages were available from rpmfind. Unfortunately, that just isn't good enough for your average user. Your average user should be able to download one file and install by double clicking or dragging and dropping.

On Linux, a user can do neither. Instead they have to go through the process of collecting all the packages they need (some of which take some research to identify) and install each one individually. Alternatively, they can chase around 10 different package managers trying to find the one that had all the stuff they need. This is not a usable design. If that offends your personal preference, then I'm sorry. That's just the way it is.

real men would just use dvdbackup to copy the disk to their hard drive, then use DVD+rw tools to burn the disk.

use dvdbackup to get a decrypted copy on your hard drive, then use dvd+rw tools to burn the disk.

does BitTorrent even work under Linux?

Uh, yes...

Try this, for example.

Anyone know a reliable source where I can get 2.6 kernel RPMS for RedHat 7.3? Rpmfind doesn't seem to have any of them yet.

"Anyone else find it interesting that Intel is working on x86-64 code?"

Maybe I'm not understanding what you're asking, but I do know that there is at least a beta (or should I say "preview") version of RedHat available that works on Intel's 64-bit CPU's codenamed "GinGin64". You can see the FTP area here.

Ever heard of RPMs? You can check the nearest RH mirror and find the version: here or here. No need to install.

Anyway, if you are not sure what's the version, don't mod it. False information is hardly "informative".

"So how about a tool which would allow users to search on the internet for packages where "missing" files can be found, install them and notify the package maintainers as to how they managed to fix it?"

Almost... rpmfind will let you search on a dependency because it can parse the rpm files for the requires and provides info. (There are more local mirrors available as well). So when you try and install a package that gives you a dependencies error, you can query it (or google, cos google also indexes rpmfind :)) and it will come back with the rpms that will satisfy that dependency.

1. Go to www.rpmfind.net
2. search for apt
3. download the appropriate rpm
4. run: rpm -Uvh apt-get-xxx.rpm (as root)
5. run: apt-get update (to get most up to date package list)
6. run: apt-get upgrade (to update any out of date packages)

I dunno, but having a built-in Caching nameserver seems pretty useful to me. Makes web browsing faster, more convenient. One click install seems to be pretty much a linux only sort of thing, too. More directly related to the speed issue, the ability to compile everything from source means that you can do a shitload of optimizations to your system, and it'll probably run a lot faster. Plus, if you have a lot of network shares, Samba is faster, and a helluva lot nicer than windows for SMB shares. Plus, Linux has a Far nicer looking, more powerful windowing system than windows, to boot.

Yes: anaconda source rpms

How about their build and dependency system ... ?

The build and dependency system is all inside the rpm program and associated libraries. Here are the source rpms for rpm. If you are worried about chicken and egg installation issues, an rpm tarball is available here.

How about their build and dependency ... database?

The actual (complete) package database for redhat 9 is available in this little known gem of a package which is included in redhat but not installed by default (and IMO should be). The spec file for rebuilding the package database can be obtained from the corresponding source rpm, provided you have a copy of all of the redhat rpms for a particular version.

In general, almost everything in redhat includes source code. If you have to ask, the source is probably available. There are a few rare instances where redhat does not provide the source code, but these are pretty obscure and you have to know redhat fairly well to run into these programs -- so well that you wouldn't need to be asking in the first place!

Yes: anaconda source rpms

How about their build and dependency system ... ?

The build and dependency system is all inside the rpm program and associated libraries. Here are the source rpms for rpm. If you are worried about chicken and egg installation issues, an rpm tarball is available here.

How about their build and dependency ... database?

The actual (complete) package database for redhat 9 is available in this little known gem of a package which is included in redhat but not installed by default (and IMO should be). The spec file for rebuilding the package database can be obtained from the corresponding source rpm, provided you have a copy of all of the redhat rpms for a particular version.

In general, almost everything in redhat includes source code. If you have to ask, the source is probably available. There are a few rare instances where redhat does not provide the source code, but these are pretty obscure and you have to know redhat fairly well to run into these programs -- so well that you wouldn't need to be asking in the first place!

Yes: anaconda source rpms

How about their build and dependency system ... ?

The build and dependency system is all inside the rpm program and associated libraries. Here are the source rpms for rpm. If you are worried about chicken and egg installation issues, an rpm tarball is available here.

How about their build and dependency ... database?

The actual (complete) package database for redhat 9 is available in this little known gem of a package which is included in redhat but not installed by default (and IMO should be). The spec file for rebuilding the package database can be obtained from the corresponding source rpm, provided you have a copy of all of the redhat rpms for a particular version.

In general, almost everything in redhat includes source code. If you have to ask, the source is probably available. There are a few rare instances where redhat does not provide the source code, but these are pretty obscure and you have to know redhat fairly well to run into these programs -- so well that you wouldn't need to be asking in the first place!

Yes: anaconda source rpms

How about their build and dependency system ... ?

The build and dependency system is all inside the rpm program and associated libraries. Here are the source rpms for rpm. If you are worried about chicken and egg installation issues, an rpm tarball is available here.

How about their build and dependency ... database?

The actual (complete) package database for redhat 9 is available in this little known gem of a package which is included in redhat but not installed by default (and IMO should be). The spec file for rebuilding the package database can be obtained from the corresponding source rpm, provided you have a copy of all of the redhat rpms for a particular version.

In general, almost everything in redhat includes source code. If you have to ask, the source is probably available. There are a few rare instances where redhat does not provide the source code, but these are pretty obscure and you have to know redhat fairly well to run into these programs -- so well that you wouldn't need to be asking in the first place!

Yes: anaconda source rpms

How about their build and dependency system ... ?

The build and dependency system is all inside the rpm program and associated libraries. Here are the source rpms for rpm. If you are worried about chicken and egg installation issues, an rpm tarball is available here.

How about their build and dependency ... database?

The actual (complete) package database for redhat 9 is available in this little known gem of a package which is included in redhat but not installed by default (and IMO should be). The spec file for rebuilding the package database can be obtained from the corresponding source rpm, provided you have a copy of all of the redhat rpms for a particular version.

In general, almost everything in redhat includes source code. If you have to ask, the source is probably available. There are a few rare instances where redhat does not provide the source code, but these are pretty obscure and you have to know redhat fairly well to run into these programs -- so well that you wouldn't need to be asking in the first place!

Using matches is old-fashioned. Use just that.

I'm a bit disappointed that Slashdot isn't closed - I wouldn't have missed it for a day or so, and it's in a good cause! Perhaps goes to show how interested the people who run this place are in the actual issues that we discuss here?

Oh, and the search facilities on RPMFind are closed as well.

RPMFind and its mirror sites are closed as well. Not the front page, but after a search query you get the warning. They say it's temporarily though.

Why learn to use a real accounting program which can print useable reports for your tax preparer when you can use Quicken or Money that let you create "money" from nowhere?

It's truly amazing to me that people can't see that MSMoney is a flaming piece of dog crap. Sure, I went from that to GnuCash an it took me a couple of days to figure out how to set up my accounts properly. But then again, I've never taken an accounting class. Ever. Which says something good for the interface and backend logic of GnuCash IMO.

I run my business with GnuCash and I can create customers, jobs, invoices, and all with *proper* accounts receivable and payable accounts that track payments in to an sales account and my bank account. All reconciled perfectly, just like my tax preparer likes it.

If you aren't running a business and find it too cumbersome then maybe try another solution, but don't say it's crap or too hard to understand. It's all about the right tool for the job.

And since I'm up here on this box I might as well address all this bitching about dependancy hell; have any of you tried building ANY application on Linux, ever? If you expect to build a application that is this complex without having to satisfy some dependencies you are insane or worse. Keep in mind people, we aren't clicking "install.exe" here, we ARE COMPILING FROM SOURCE CODE. It's not intended to be "Point and Click Easy". Find an RPM, in fact, here you go -> RPMfind.com

I for one say hats off to the GnuCash developers. When I first started using it I had some ideas for modifications and I got in touch immediately with the developer working on that section of the app and had a nice conversation about what was currently planned and what was possible right then.

GnuCash is a great open source success story, and I for one will be lurking on the user mailing list looking for ways to help.

By far, hunting down layer after layer of dependency while trying to install software, only to meet conflicts is my biggest problem.

Not to mention trying to download something otherwise good like XMMS-Crossfade and findingdozens of near-identically labeled files, offering 'src', 'yellowdog', 'ppc', 'i386', 'i586', '1mdk', 'fr1'... and the same for about 3 older versions.

With windows, there's usually a vendor website with one clearly marked binary or zip.

Just my $0.02,

Michael

If you have a package in mind, there are few better places to look than RPMfind, use your "local" mirror:
East Coast (MIT)
West Coast (Speakeasy)
France #1 (INRIA)
France #2 (INSA)

If you have a package in mind, there are few better places to look than RPMfind, use your "local" mirror:
East Coast (MIT)
West Coast (Speakeasy)
France #1 (INRIA)
France #2 (INSA)

If you have a package in mind, there are few better places to look than RPMfind, use your "local" mirror:
East Coast (MIT)
West Coast (Speakeasy)
France #1 (INRIA)
France #2 (INSA)

If you have a package in mind, there are few better places to look than RPMfind, use your "local" mirror:
East Coast (MIT)
West Coast (Speakeasy)
France #1 (INRIA)
France #2 (INSA)

The release that is contained in Rawhide (check rpmfind.net) is based off a pre-release. A new RPM should be available quite soon with the final version (doesn't take very long for the mirrors to catch up).

Here's one for RawHide that works just fine on RH9. And don't forget to download the rest of the Mozilla 1.4-6 packages. It's not as new as RC2, but it's got the nice antialiasing stuff and has some improvements over 1.3.

Yes, I have heard of the great "apt-get" and will definitely exercise it a bit.

Even if you install packages from CD-Rom, you'll use the same interface as if you were getting it live from HTTP. The only difference is that it'll prompt you to insert the right disc first... and since most packages are small, it'll often take more time for you to find the disc than to just get it from the server.

You didn't mention if you had downloaded the stable or testing Debian... testing is generally prefered, because it's not as painfully obselete. If you value stability, "stable" is good of course. But if you want to have fun and experiment, then newer is better. And if you're using "testing", then you'll probably want to keep up with changes made after the CDs were burnt. Debian "testing" CD-Roms go obselete really fast.

I don't know why you have a problem with the naming of RPMs. I find that it is usually the same as the program or package name.

RPM names also contain at least the version string, and often an indication of which architecture the software will run on. Sometimes supported OS versions are mixed in too. For example, when I tried to install a package on a Red Hat system, I had to download that RPM. Then go to install it, and find out I needed multiple other RPMs first, which need even more RPMs to work.

The point of apt-get is you, the installing user, never even see the *.deb file that the package actually comes in. The hunt for dependencies is completely hidden from you.

Of course, RedHat users can optionally run apt-get themselves, but that's not formally supported by the distribution developer.

I won't go into the whole problem of not getting *.deb files for new, bleeding edge software. It's an accepted fact that Debian users who wish to try something brand-new will be compiling it themselves.

Yes, I have heard of the great "apt-get" and will definitely exercise it a bit.

Even if you install packages from CD-Rom, you'll use the same interface as if you were getting it live from HTTP. The only difference is that it'll prompt you to insert the right disc first... and since most packages are small, it'll often take more time for you to find the disc than to just get it from the server.

You didn't mention if you had downloaded the stable or testing Debian... testing is generally prefered, because it's not as painfully obselete. If you value stability, "stable" is good of course. But if you want to have fun and experiment, then newer is better. And if you're using "testing", then you'll probably want to keep up with changes made after the CDs were burnt. Debian "testing" CD-Roms go obselete really fast.

I don't know why you have a problem with the naming of RPMs. I find that it is usually the same as the program or package name.

RPM names also contain at least the version string, and often an indication of which architecture the software will run on. Sometimes supported OS versions are mixed in too. For example, when I tried to install a package on a Red Hat system, I had to download that RPM. Then go to install it, and find out I needed multiple other RPMs first, which need even more RPMs to work.

The point of apt-get is you, the installing user, never even see the *.deb file that the package actually comes in. The hunt for dependencies is completely hidden from you.

Of course, RedHat users can optionally run apt-get themselves, but that's not formally supported by the distribution developer.

I won't go into the whole problem of not getting *.deb files for new, bleeding edge software. It's an accepted fact that Debian users who wish to try something brand-new will be compiling it themselves.

Yes, I have heard of the great "apt-get" and will definitely exercise it a bit.

Even if you install packages from CD-Rom, you'll use the same interface as if you were getting it live from HTTP. The only difference is that it'll prompt you to insert the right disc first... and since most packages are small, it'll often take more time for you to find the disc than to just get it from the server.

You didn't mention if you had downloaded the stable or testing Debian... testing is generally prefered, because it's not as painfully obselete. If you value stability, "stable" is good of course. But if you want to have fun and experiment, then newer is better. And if you're using "testing", then you'll probably want to keep up with changes made after the CDs were burnt. Debian "testing" CD-Roms go obselete really fast.

I don't know why you have a problem with the naming of RPMs. I find that it is usually the same as the program or package name.

RPM names also contain at least the version string, and often an indication of which architecture the software will run on. Sometimes supported OS versions are mixed in too. For example, when I tried to install a package on a Red Hat system, I had to download that RPM. Then go to install it, and find out I needed multiple other RPMs first, which need even more RPMs to work.

The point of apt-get is you, the installing user, never even see the *.deb file that the package actually comes in. The hunt for dependencies is completely hidden from you.

Of course, RedHat users can optionally run apt-get themselves, but that's not formally supported by the distribution developer.

I won't go into the whole problem of not getting *.deb files for new, bleeding edge software. It's an accepted fact that Debian users who wish to try something brand-new will be compiling it themselves.

Does anyone know if RH Advanced Server is redistributable? The 5-year life cycle is really appealing, if I could just download the updates. (which is what I do now, I don't bother with up2date).

But I've never seen ISO's available for AS. Anyone know why not?

rpmfind.net and have no problems.

This crap happens to me a lot too, but apt has nothing to do with it. A simple "rpm -e somepackage", sans apt installed, will sometimes lock. It seems RH9's rpm has serious bugs. And there is no update to it as of this time.

Lemme look at RawHide... yeah, here's an rpm package. Maybe this one will work better?