I thought of that. However, the USDA usually increases its number of nutrients ever few revs of the database. gnutrition uses v13 and the current is v15.
Plus, I compilee it on RH9 and it bombed at some point when I ran it. The docs speak of RH 7.1 I think.
Holy crap... I didn't realize that openssh defaulted to 3des (at least in Redhat RPMs). I forced both my server and clients to use blowfish and the interactive lag over my 33.6 modem connection dropped considderably.
Thanks for the tip. You learn something every day on this board!
I can't find a valid use for this sort of system. Can anyone?
Apart from the old "more choice is better" argument, I firmly believe we should celebrate lean systems and minimalist configurations.
The screenshots of Twin brought back memories of running DESQView on DOS. Now that was a kick-ass program. And I never felt cramped in my 80x25 character screen.
This reminds me of an old DOS text editor. It was fairly full-featured (better than DOS's own EDIT program). The really cool thing was that is took up a single floppy disk sector, or 512 bytes.
I love this kind of stuff. Ever see the tiny linux utility suite? Same idea, though I can't remember the name. It's used for embeded systems, I think.
I must agree with the grandparent post -- it's pretty difficult. I'm not a Linux god, but I'm no slouch. I can usually muddle my way through anything, but I couldn't get FreeS/WAN working between 2 Linux boxes a few days ago.
I think better documentation and/or a better HOWTO would be benneficial.
Another pet peeve of mine is how damned hard using mixmaster remailers is. I've toyed with these things on and off for nearly ten years. I've never really figured it out too well. There aren't even any good unix front-ends for these things. Best I can find is a DOS program and a crusty Windows program ("My Private Idaho" I think?). And all documention is 5 years old or more. (Never mind the general mumblings of distrust I perceive in the mixmaster servers themselves).
Maybe these are just 2 items I just dont "get" -- everyone seems to have blocks like these.
I'd say it's more a function of the service (DHCP?) than anything. You can't much simpler than DHCP. I'd never expect to see an NT domain controller, file/print server, Exchange, or IIS server make it more than a couple of months without a reboot.
That's like being proud of a UNIX/Linux server for having a 3-year uptime when all it does is serve ntp queries! The lack of a power interruption is more impressive than the machine staying up.
Since most of these types of notices are form-letter-style, can't one request a paper trail from the organization to prove that 1) They do, in fact, represent the particular copyright holder; and 2) That the particular copyright holder does, in fact, own the copyright/trademark on the software being made available?
I recall some ROM site (TI99/4A site perhaps?) where the owner got explicit permission from the copyright holders to post their ROMS, but he still got a letter from these goons.
Short of the discovery process of a lawsuit, is there any way to force the hand of these organizations to prove they are in the right for each specific case?
I don't know, as I only use v1.3 of Mozilla. Aside from being able to selectively kill pop-up windows, manage cookies and images (which Mozilla does just fine), it's an ad blocker. It lets you use regular expressions to block URLs and you can even rewrite html on the fly as it traverses the proxy. This ability give you the power to disable arbitrary javascript code by substituting annoying functions with a name that has no meaning to the javascript engine, thus effectively rendering the feature inactive.
As a sample, I have this in one of my config files:
# Forcing URLs to open in new windows. (http://www.gozer.org/privoxy) # s/\s+target=['" ]?(_blank|_new)['"]?//ig
This disables HTML links that launch a new browser window by re-writing the HTML on the fly. I don't know why in hell people use this tag, but it annoys me to no end. Moz 1.4 may now have this, but this simple example should illustrate the power of the program.
Privoxy's source has its roots in the junkbuster program, but it's been re-written with much better features.
Get yourself a copy of Privoxy (www.privoxy.org) -- it's Free, and it's really sweet. I've stopped using Mozilla's anti-annoyance features because privoxy does it better. I especially like the ability to disable links that launch new windows -- man, do I hate those.
I understand the RPM dependency hell very well. I recently did a full, clean RedHat 9 install. I then downloaded all the source RPMs from freshrpms, mostly for the multimedia capabilities. A quick 1-line bash script went through the entire batch and attempted to build them. Of course, some needed to be built and installed before others, so about 30% failed. I installed what did build, then repeated this process several more times. The mplayer package was the worst by far.
Anyway, I don't understand how anyone has trouble installing packages from source. You just need to partition them appropriately. I wish distributions used a similar method so they could keep parallel versions of programs and libraries installed.
Take openssh, for example:
My typical build of openssh requires: zlib, openssl, and tcp_wrappers.
I use a structure I call/mfs ("My File System"). I could use/usr/local for the same thing, but a customized directory will prevent collisions in/usr/local (the usual default prefix for configure scripts).
Under/mfs I have directories "dist" (the tarballs), "src" (where I untar and build each package), and "pkg" where I install packages.
So I start with zlib: "./configure --prefix=/mfs/pkg/zlib/1.1.4 ; make ; make test ; make install".
I repeat with tcp_wrappers, openssl, and finally openssh. So now I have the most current versions:
/mfs/pkg/zlib/1.1.4
/mfs/pkg/tcp_wrappers/7.6
/mfs/pkg/openssl/0.9.7a
/mfs/pkg/openssh/3.6.1p1
It should go without saying that I configure openssh to use the zlib, openssl, and wrappers libraries under/mfs, rather than the default system libraries. To the anal purists out there, I don't do this with all libraries (such as glibc), as it would drive me insane -- but it could theoretically be done.
Here's where it gets elegant (or convoluted, depending on your tolerance for complexity). Under each package's directory, I use a symlink from the version I wish to use on a regular basis to "std".
So, under/mfs/pkg/openssh, I may have directories 3.6.1p1, 3.0.1p1, and 2.9.9p1. Let's say that I want to use the latest sshd, so I run "cd/mfs/pkg/openssh ; ln -s 3.6.1p1 std". I then cd back up to/mfs. I then issue "lndir pkg/openssh/std". Actually, I have a script in/mfs that automatically removes all existing links under/mfs (avoiding the "pkg" dir, for obvious reasons) then re-linking every package with a "std" link. (Note I don't use a "std" link -- and thus don't lndir -- for libraries without runable binaries). If you don't know how lndir works, check it out (it's from the XFree86 distribution, though that might not be where it originated.).
After running lndir (or my script), I now have/mfs/{bin,etc,var,lib,sbin}. I point my sshd startup script to always use/mfs/sbin/sshd, which is actually a link to/mfs/pkg/openssh/std/sbin/sshd. Since std is a symlink to the version I wish to use, I can change to a newer or older version by simply stopping sshd, changing the "std" link to point to another version, and restarting sshd.
The beauty is that still have other versions available to me. Say the scp provided in 3.6.1p1 has an irritating bug (not the case, but just imagine). If my normal PATH has/mfs/bin, I'll get scp v3.6.1p1, but I can fall back to running/mfs/pkg/openssh/3.0.1p1/bin/scp.
This technique is especially valuable in multi-user systems, where libraries and applications of different versions (think compilers, for example) have dedicated users who aren't ready to upgrade.
Sorry for the really long post, but this idea works extremely well, IMHO, and I'm surprised that no distros use a similar technique for maintaining parallel versions. If RPM used this technique, you'd never run into the case where a new app needs a newer library version, but upgrading that library isn't possible since other major applications require that specific version (such as KDE needing a specific version of libpng and libcrypt).
I think it could work, but it'll take a looooong time to make any inroads. Look at the open source models for inspiration.
For example, let's say I have a bunch of tunes I've produced and I add them to the Creative Commons site above. Though I didn't see a license that quite matched the GPL, imagine I had my stuff under a license that said, "You can use this work as-is for any purpose, public or private. You can even make derivatives of this work. However, if you release the derivative (play in public or broadcast on any medium), you must apply the same license to that derivative work."
Say FOX News wants to air one of my pieces as the background music for a news clip. If left unmodified, they can do that without paying me dime. If they do edit the work themselves, they must allow anyone to redistribute that tune (say either from a recording off of TV or via a copy on their website). If FOX wants exclusive use rights for the recording, they can pay me to record the song to their specs.
In all three examples, I get exposure, which may lead to for-pay contracts. And in one of the scenarios, I can get money for a re-recording.
I don't program or record music, so my analogy may be a bit off, but there is potential. This exact example may not quite work for written or visual works without some tweaking.
I see things getting muddled, though. For music, does the license apply to the recording, the lyrics, or the composition? Artists will need to be verbose about just what they are releasing under these licenses.
The cell phones are not stuck in such a setup -- they site in a cradle. You are free to take them with you when you leave. And, yes, when you do remove them, the home lines do not work.
There were two points to the larger thread I was addressing. One was ditching your land-line entirely for a cellphone. Two, someone was worried about his girlfriend yapping for hours on a cell phone (versus a landline) due to the claims that the EM radiation from cellphones was harmful. The whole-house tie-in system I mentioned eliminates this concern (at least while at home).
The syntax for ipchains / iptables is just horrible. It doesn't read anything close to English.
I could say the same thing for perl, but I'd have a hard time coming down as hard on it as you have on iptables. However, it's all I've ever known in the world of filtering (except for Cisco's and AIX's filter rules). I guess syntax is a matter of taste and what we're comfortable with.
The other horrible thing about Linux packet filtering is that it only *just* got NAT figured out. Only took them 3 releases (and how many years??) to get that one. IPFW / IPF / PF have had that for several years now.
Ah, now a technical reason. Didn't ipchains have NAT, or is masqerading a totally different conecpt? I used to have multiple clients routing via an ipchains box when I had broadband.
Since you've obviously run both side by side, can you comment on the speed of both? There's measurable overhead when enabling iptables (crude tests on low-end hadware, but I was able to clock a difference in load). Is the same true for the *BSDs?
You know, there are whole-house cellphone systems. For a couple of hundred bucks, you can tie in your cell phone to your home's wiring. When you pick up a regular receiver, it routes the call out the cellphone. Likewise, when the cellphone rings, it rings the normal phones. I lost my link, but do a google and find it. Cool stuff.
What's your beef with Linux's filters? I've found iptables to be really nice -- much better than ipchains (never used ipfwadm).
I just installed NetBSD for the first time (on VMWare on my Redhat box), so I guess I'll get a chance to see first-hand the *BSD side of packet filtering. Maybe I'll have a different opinion of iptabels in a couple of months.
Look at the linux crypto patch. There's a driver that hooks into the loopback device. You create a file, enable the crypto on it, mkfs, then mount it.
There's no turn-key open source solution out there, at least none that I know of. It's a pain in the ass, but it will work.
What I want is swap/memory encryption. One can encrypt/tmp using the method mentioned above. But the really paranoid will want to encrypt the other two as well. Go on, grep/etc/kcore for the passwords you use on your linux box. Scary, eh?
or muscled into compliance by special interests, what's the current status of various VPN and/or IPSEC open source implementations for Linux/UNIX?
I'd love to create some crypto traffic between my home box and work machine (besides the normal SSH, of course). The more white noise packets floating around out there, the better. TCP/IP spook fodder, if you will.
Better yet, is there an encrypted, routed "internet" I can plug into at will when I'm online, just to obfuscate my traffic a bit? Or is that what Freenet is about?
I still buy Cisco, because it's not my money I'm spending. However, you bet your ass that if it was, I'd be looking elsewhere. I bought some non-cisco equipment before and it was nicer to use, cheaper, and performed much better.
Why would you do your employer/clients this disservice if you know better alternatives exist?
I would argue that stability (or the OS) is a big win. I would take an educated guess that performance would be a big win, as well.
Example: I'm running a big honkin' calculation in Excel or a huge query in Access on my workstation. It's CPU-intensive, and it'll take 30-60 minutes to complete. (Anyone with a real-world example, please speak up.) I'd be pretty miffed if reading email in MS Lookout caused the machine to go tits-up. Also, I'd wager that Linux's newer schedulers would make running these large apps together less painfull.
In practice, I've been unimpressed with the standard Wine product. I haven't shelled out money for Crossover or Transgaming. I have test-driven Win4Lin (http://www.trelos.com, iirc), and I was pretty damned impressed. It's fast, but only works with Win95/98 -- the NT family isn't supported. I use VMWare on a daily basis for those few Windows apps I haven't kicked the habbit for (Streets and tax software). VMWare works flawlessly, but it's too expensive (I purchased when they had the $100 hobbiest price, and upgraded once for $100, but I cannot justify the most recent $100 upgrade.). Of course Win4Lin and VMWare techniaclly require an OS license, whereas Wine doesn't (unless you truly obey MS's EULA's).
Wine is cool, but in the nearly 10 years I've followed it, I have yet to consider it viable. If only plex86 would get in gear and compete with VMWare head-on -- VMWare is getting too big for its britches (another reason I refuse to upgrade this time) and they need some humility, just like Accelerated-X did when XFree finally got 3D and multi-head working well.
Wait 'til the Homeland Security goons
on
PDA/Radiation Detector
·
· Score: 2, Interesting
figure out someone simply ported the old HP48 Tricorder program to the PDAs and cell phones.
To go really off topic for a second, the items with the highest percent mark-up are batteries. That's the reason they are placed all over the store.
I go with dollar-store batteries myself. The only devices I use them for with any regularity are my Mag-Lites (D cells), my HP 48G and SX calcs (AAA), and my GPS and camera flash (AA). No, I haven't done a controlled drain test, or even "clocked" how long they hold up in the devices, but they sure feel like they last 75-90% of what the premium batteries do, and at 15%-to-25% the cost, it works for me.
If I had time to research the best brands, I may go with rechargeable batteries. More eco-frindly.
I'd be happy if there were an open spec, with perhaps a reference implementation, available. Maybe.
Free codecs just aren't enough for many people, myself included. I won't use Real fomats because of this reason, even though there's a player for Linux.
Free, open apps are a little better. GIF, PDF, and MP3 are things that fall into this category. Yeah, there's tons of open and free software out there for these, but technically, they're encumbered with patents, licensing, etc. But at least I can trust the folks who write apps (the open source authors, anyways). These are handy, but there's still an "impurity" with using these formats.
The ideal is open source apps/codecs which are not laden with licensing and patent restrictions. The Vorbis project (or is it the Ogg proejct?) is a good idea. I'm sick of trailers and video clips being released in Real, QuickTime, and M$ formats. You would think that from a purely cost/licensing perspective, site owners would want to use a very open and well-defined standard that would reach all platforms (like MPEG)? It just doesn't make sense.
No, I for one will not be happy about this. I guess I'll be one of the complainers.
I think I follow you now. What you're looking for is a binary sandbox, just like (as you state in another post) Java bytecode apps are run in virutal isolation, with the Java "VM" keeping strict tabs on the system calls the application makes.
The idea sounds pretty neat. But is sounds like a pretty tough challenge. You may just as well ask for a complete overhaul of the way unix systems work (all-powerful root account is evil, etc.). As others have pointed out, the best bet seems to be the various ACL packages to limit what certain users and applications can read/write. LIDS, medusa, grsecurity, and rsbac (to name a few) do these kinds of things.
Plus, I compilee it on RH9 and it bombed at some point when I ran it. The docs speak of RH 7.1 I think.
Thanks for the tip. You learn something every day on this board!
Apart from the old "more choice is better" argument, I firmly believe we should celebrate lean systems and minimalist configurations.
The screenshots of Twin brought back memories of running DESQView on DOS. Now that was a kick-ass program. And I never felt cramped in my 80x25 character screen.
This reminds me of an old DOS text editor. It was fairly full-featured (better than DOS's own EDIT program). The really cool thing was that is took up a single floppy disk sector, or 512 bytes.
I love this kind of stuff. Ever see the tiny linux utility suite? Same idea, though I can't remember the name. It's used for embeded systems, I think.
Diversity is the key.
I think the MPAA and RIAA cover that many just by themselves.
I think better documentation and/or a better HOWTO would be benneficial.
Another pet peeve of mine is how damned hard using mixmaster remailers is. I've toyed with these things on and off for nearly ten years. I've never really figured it out too well. There aren't even any good unix front-ends for these things. Best I can find is a DOS program and a crusty Windows program ("My Private Idaho" I think?). And all documention is 5 years old or more. (Never mind the general mumblings of distrust I perceive in the mixmaster servers themselves).
Maybe these are just 2 items I just dont "get" -- everyone seems to have blocks like these.
That's like being proud of a UNIX/Linux server for having a 3-year uptime when all it does is serve ntp queries! The lack of a power interruption is more impressive than the machine staying up.
I recall some ROM site (TI99/4A site perhaps?) where the owner got explicit permission from the copyright holders to post their ROMS, but he still got a letter from these goons.
Short of the discovery process of a lawsuit, is there any way to force the hand of these organizations to prove they are in the right for each specific case?
As a sample, I have this in one of my config files:
This disables HTML links that launch a new browser window by re-writing the HTML on the fly. I don't know why in hell people use this tag, but it annoys me to no end. Moz 1.4 may now have this, but this simple example should illustrate the power of the program.
Privoxy's source has its roots in the junkbuster program, but it's been re-written with much better features.
Get yourself a copy of Privoxy (www.privoxy.org) -- it's Free, and it's really sweet. I've stopped using Mozilla's anti-annoyance features because privoxy does it better. I especially like the ability to disable links that launch new windows -- man, do I hate those.
Anyway, I don't understand how anyone has trouble installing packages from source. You just need to partition them appropriately. I wish distributions used a similar method so they could keep parallel versions of programs and libraries installed.
Take openssh, for example:
My typical build of openssh requires: zlib, openssl, and tcp_wrappers.
I use a structure I call /mfs ("My File System"). I could use /usr/local for the same thing, but a customized directory will prevent collisions in /usr/local (the usual default prefix for configure scripts).
Under /mfs I have directories "dist" (the tarballs), "src" (where I untar and build each package), and "pkg" where I install packages.
So I start with zlib: "./configure --prefix=/mfs/pkg/zlib/1.1.4 ; make ; make test ; make install".
I repeat with tcp_wrappers, openssl, and finally openssh. So now I have the most current versions:
It should go without saying that I configure openssh to use the zlib, openssl, and wrappers libraries under /mfs, rather than the default system libraries. To the anal purists out there, I don't do this with all libraries (such as glibc), as it would drive me insane -- but it could theoretically be done.
Here's where it gets elegant (or convoluted, depending on your tolerance for complexity). Under each package's directory, I use a symlink from the version I wish to use on a regular basis to "std".
So, under /mfs/pkg/openssh, I may have directories 3.6.1p1, 3.0.1p1, and 2.9.9p1. Let's say that I want to use the latest sshd, so I run "cd /mfs/pkg/openssh ; ln -s 3.6.1p1 std". I then cd back up to /mfs. I then issue "lndir pkg/openssh/std". Actually, I have a script in /mfs that automatically removes all existing links under /mfs (avoiding the "pkg" dir, for obvious reasons) then re-linking every package with a "std" link. (Note I don't use a "std" link -- and thus don't lndir -- for libraries without runable binaries). If you don't know how lndir works, check it out (it's from the XFree86 distribution, though that might not be where it originated.).
After running lndir (or my script), I now have /mfs/{bin,etc,var,lib,sbin}. I point my sshd startup script to always use /mfs/sbin/sshd, which is actually a link to /mfs/pkg/openssh/std/sbin/sshd. Since std is a symlink to the version I wish to use, I can change to a newer or older version by simply stopping sshd, changing the "std" link to point to another version, and restarting sshd.
The beauty is that still have other versions available to me. Say the scp provided in 3.6.1p1 has an irritating bug (not the case, but just imagine). If my normal PATH has /mfs/bin, I'll get scp v3.6.1p1, but I can fall back to running /mfs/pkg/openssh/3.0.1p1/bin/scp.
This technique is especially valuable in multi-user systems, where libraries and applications of different versions (think compilers, for example) have dedicated users who aren't ready to upgrade.
Sorry for the really long post, but this idea works extremely well, IMHO, and I'm surprised that no distros use a similar technique for maintaining parallel versions. If RPM used this technique, you'd never run into the case where a new app needs a newer library version, but upgrading that library isn't possible since other major applications require that specific version (such as KDE needing a specific version of libpng and libcrypt).
For example, let's say I have a bunch of tunes I've produced and I add them to the Creative Commons site above. Though I didn't see a license that quite matched the GPL, imagine I had my stuff under a license that said, "You can use this work as-is for any purpose, public or private. You can even make derivatives of this work. However, if you release the derivative (play in public or broadcast on any medium), you must apply the same license to that derivative work."
Say FOX News wants to air one of my pieces as the background music for a news clip. If left unmodified, they can do that without paying me dime. If they do edit the work themselves, they must allow anyone to redistribute that tune (say either from a recording off of TV or via a copy on their website). If FOX wants exclusive use rights for the recording, they can pay me to record the song to their specs.
In all three examples, I get exposure, which may lead to for-pay contracts. And in one of the scenarios, I can get money for a re-recording.
I don't program or record music, so my analogy may be a bit off, but there is potential. This exact example may not quite work for written or visual works without some tweaking.
I see things getting muddled, though. For music, does the license apply to the recording, the lyrics, or the composition? Artists will need to be verbose about just what they are releasing under these licenses.
There were two points to the larger thread I was addressing. One was ditching your land-line entirely for a cellphone. Two, someone was worried about his girlfriend yapping for hours on a cell phone (versus a landline) due to the claims that the EM radiation from cellphones was harmful. The whole-house tie-in system I mentioned eliminates this concern (at least while at home).
I could say the same thing for perl, but I'd have a hard time coming down as hard on it as you have on iptables. However, it's all I've ever known in the world of filtering (except for Cisco's and AIX's filter rules). I guess syntax is a matter of taste and what we're comfortable with.
The other horrible thing about Linux packet filtering is that it only *just* got NAT figured out. Only took them 3 releases (and how many years??) to get that one. IPFW / IPF / PF have had that for several years now.
Ah, now a technical reason. Didn't ipchains have NAT, or is masqerading a totally different conecpt? I used to have multiple clients routing via an ipchains box when I had broadband.
Since you've obviously run both side by side, can you comment on the speed of both? There's measurable overhead when enabling iptables (crude tests on low-end hadware, but I was able to clock a difference in load). Is the same true for the *BSDs?
You know, there are whole-house cellphone systems. For a couple of hundred bucks, you can tie in your cell phone to your home's wiring. When you pick up a regular receiver, it routes the call out the cellphone. Likewise, when the cellphone rings, it rings the normal phones. I lost my link, but do a google and find it. Cool stuff.
What's your beef with Linux's filters? I've found iptables to be really nice -- much better than ipchains (never used ipfwadm).
I just installed NetBSD for the first time (on VMWare on my Redhat box), so I guess I'll get a chance to see first-hand the *BSD side of packet filtering. Maybe I'll have a different opinion of iptabels in a couple of months.
There's no turn-key open source solution out there, at least none that I know of. It's a pain in the ass, but it will work.
What I want is swap/memory encryption. One can encrypt /tmp using the method mentioned above. But the really paranoid will want to encrypt the other two as well. Go on, grep /etc/kcore for the passwords you use on your linux box. Scary, eh?
I'd love to create some crypto traffic between my home box and work machine (besides the normal SSH, of course). The more white noise packets floating around out there, the better. TCP/IP spook fodder, if you will.
Better yet, is there an encrypted, routed "internet" I can plug into at will when I'm online, just to obfuscate my traffic a bit? Or is that what Freenet is about?
Why would you do your employer/clients this disservice if you know better alternatives exist?
Example: I'm running a big honkin' calculation in Excel or a huge query in Access on my workstation. It's CPU-intensive, and it'll take 30-60 minutes to complete. (Anyone with a real-world example, please speak up.) I'd be pretty miffed if reading email in MS Lookout caused the machine to go tits-up. Also, I'd wager that Linux's newer schedulers would make running these large apps together less painfull.
In practice, I've been unimpressed with the standard Wine product. I haven't shelled out money for Crossover or Transgaming. I have test-driven Win4Lin (http://www.trelos.com, iirc), and I was pretty damned impressed. It's fast, but only works with Win95/98 -- the NT family isn't supported. I use VMWare on a daily basis for those few Windows apps I haven't kicked the habbit for (Streets and tax software). VMWare works flawlessly, but it's too expensive (I purchased when they had the $100 hobbiest price, and upgraded once for $100, but I cannot justify the most recent $100 upgrade.). Of course Win4Lin and VMWare techniaclly require an OS license, whereas Wine doesn't (unless you truly obey MS's EULA's).
Wine is cool, but in the nearly 10 years I've followed it, I have yet to consider it viable. If only plex86 would get in gear and compete with VMWare head-on -- VMWare is getting too big for its britches (another reason I refuse to upgrade this time) and they need some humility, just like Accelerated-X did when XFree finally got 3D and multi-head working well.
figure out someone simply ported the old HP48 Tricorder program to the PDAs and cell phones.
I go with dollar-store batteries myself. The only devices I use them for with any regularity are my Mag-Lites (D cells), my HP 48G and SX calcs (AAA), and my GPS and camera flash (AA). No, I haven't done a controlled drain test, or even "clocked" how long they hold up in the devices, but they sure feel like they last 75-90% of what the premium batteries do, and at 15%-to-25% the cost, it works for me.
If I had time to research the best brands, I may go with rechargeable batteries. More eco-frindly.
Yeah, I caught that, too. I thought I might have been over-reacting, but your response shows that my nerves weren't the only ones hit.
How does this utility compare with dd_rescue for data recovery? Anyone used both?
Free codecs just aren't enough for many people, myself included. I won't use Real fomats because of this reason, even though there's a player for Linux.
Free, open apps are a little better. GIF, PDF, and MP3 are things that fall into this category. Yeah, there's tons of open and free software out there for these, but technically, they're encumbered with patents, licensing, etc. But at least I can trust the folks who write apps (the open source authors, anyways). These are handy, but there's still an "impurity" with using these formats.
The ideal is open source apps/codecs which are not laden with licensing and patent restrictions. The Vorbis project (or is it the Ogg proejct?) is a good idea. I'm sick of trailers and video clips being released in Real, QuickTime, and M$ formats. You would think that from a purely cost/licensing perspective, site owners would want to use a very open and well-defined standard that would reach all platforms (like MPEG)? It just doesn't make sense.
No, I for one will not be happy about this. I guess I'll be one of the complainers.
The idea sounds pretty neat. But is sounds like a pretty tough challenge. You may just as well ask for a complete overhaul of the way unix systems work (all-powerful root account is evil, etc.). As others have pointed out, the best bet seems to be the various ACL packages to limit what certain users and applications can read/write. LIDS, medusa, grsecurity, and rsbac (to name a few) do these kinds of things.