Don't bother with setting up an FTP site, CVS Server, et all. Here's how to do it so that each collaborator is completely anonymous while everyone in the group maintains certainty of authenticity both by authors in the source tree:
Next, create a NEW PGP key (that's not related to your name, DUH!) and upload it to one of the many PGP Keyring servers, such as at pgp.mit.edu.
Next, create an internal CVS tree with your source code. Tar it up, split it, md5sum the file, and attach both to a mail message pgp signed with your anonymous key. Mail this to the remailer with a USENET news header of your favorite newsgroup (make certain all your friends know the correct newsgroup to puruse).
Now, all your friends need only suck down the attachment from the agreed upon USENET newsgroup and create their own CVS trees.
They all follow the same steps, only they post patches, along with an MD5 sum of the patch+original CVS source tree (tar'd, or individual file)... this way you know when you're applying the patch that it's against a current revision).
There you go, because you're using an anonymous remailer it's completely anonymous. Because everyone is signing the USENET post with their (anonymous) PGP keys it's absolutely certain proof of authenticity from the author, and because you're MD5 suming either the source tree tarball or individual files you can be certain that the patch is against a particular revision of the source tree/file.
Most anything I've ever released (not much, mind you) has been under my own personal license that goes something like this: "Do not abuse this software under penalty of death. For more information, contact the author."
Is my license really any less credible than the GPL or any other license slapped on any piece of software?
Yes, Your license is really that less credible. You don't think that just because your (crazy) users agreed to a shrink wrap license with a death penalty clause that you wouldn't wind up in jail soon after having enacted the penalty, do you? Naaaa, I didn't think so either.
It's my understanding (not as a lawyer) that the GPL is more credible constitutionally than shrink wrap licenses is because most of the clauses in a shrink wrap relate to acceptable use rather than restrictions on duplication. For example, many Microsoft shrinkwrap licenses prevent reverse engineering; some prevent transfer to another system; demand multiple payments for the same license under certain circumstances; and indemnify the author from any fitness of function or warranty.
But the GPL is different. The GPL prevents duplication of an intellectual property licensed as such under a few very specific circumstances. Developers must offer source level changes to the recipient of any binary of which they've derived a previous work released under the GPL (meaning their changes must be released under a license which won't conflict with these clauses). Which basically says, "you can't distribute this unless you follow my rules of citation and release the source of your changes to your recipients. If you accept these rules you may copy to your heart's content."
Wanna bet you'll see something like that on your next Microsoft click through license??? I betcha NO!:-)
Unfortunately, MacOS has this nasty tendency to not run on even all the Mac's available at their launch. Forget running a new MacOS on anything but the latest hardware. That upgraded NuBus Mac won't run OSX nor will those PCI Macs. Nor, for that matter, will the G3s or some of the G4s. Funny thing. You'd think Apple wanted you to buy a new computer...
Strangely enough, I can't run Solaris 8 on my Sun 3x, HP-UX 11 on my HP300, or Windows 2000 on my '286.
This is a ridiculous argument on it's face simply because MaxOS X is a completely redesigned OS based on Mach and BSD, not the original MacOS codebase. That Apple isn't (formally) supporting older PowerPC hardware is no surprise, though I bet that getting the core OS to run on most PowerMacs won't be terribly difficult. Look, I've never bought a Mac. The last computer I bought from Apple was a II/e, so don't think I'm biased in Apple's favor -- but I think your argument simply doesn't hold water.
Um, MacOS 7 didn't do memory protection nor preemptive multitasking, right?
Nor does Windows 3.x, 9x. It doesn't support true preemptive multitasking nor a real memory protection model in order to maintain backward compatibility; everything runs in ring 0. It's true that MacOS 7/8/9 shares these limitations with Microsoft's Win9x/ME brethren. However, MacOS has a far superior interface to Windows (INHO). I'll give but one flagrant example:
Windows 3.x abstracted the filesystem away from users through the use of "Program Groups", which had no relation to the filesystem whatsoever. For this reason, many Windows users never learned basic filesystem concepts, such as directory hierarchies. This model continued in Win9x through the use of the "start" button, even though explorer provided access to the filesystem. To this day I know many Windows users who have NO IDEA what the difference is between a directory and a file, and don't care. This means that when they lose files in the filesystem they have no way to find them again.
MacOS represents the filesystem as a set of folders within folders. Let's not even get into a debate on the superiority of HFS to FAT... filesystem metadata support under HFS is so superior to FAT it's just a joke.
That said, I won't consider buying a Mac until they release OS X. I am a UNIX weenie and have been using UNIX since the '80s. NeXTStep is probably the best operating environment I've ever used.
Finally, even given that your argument were true: how does this change Microsoft's anti-competitive and exclusionary licensing behavior with the hardware integrators. Are you arguing that because Win9x has "preemptive multitasking" that Apple should not have been given entry into the market?
A GPL Windows/QT could fork from the free codebase
on
Qt Going GPL
·
· Score: 3
There's nothing stopping developers from forking the FreeQT codebase to create a new Windows based QT. Frankly, I think the Windows port of QT is one of the best advantages of QT over GTK+. Windows support with GTK is still in it's infancy while QT is quite usable.
The way to bring Windows desktop users over to Free Software is to create cross platform Apps which reduce the need for Windows as a base platform in order to create a migration path for users. That means porting the new StarOffice and KOffice to Windows, giving users a chance to feel comfortable with the new environment, and then waiting for the next costly Windows upgrade to convince the users "there's a cheaper way..."
And it's a damn shame, but the article alludes to why in this paragraph:
Armed with the executive staff's approval, Mark Gonzales, the project marketing manager, made the rounds of PC clone vendors to gauge their interest in bundling Star Trek on their systems. Most were intrigued, but argued that they couldn't afford to pay much for it because their contracts for Windows 3.1 forced them to pay a royalty to Microsoft for every computer shipped, regardless of what operating system it contained. (This anti-competitive practice eventually landed Microsoft in trouble with the Department of Justice.)
Apple didn't stand a chance on the Intel platform, and they knew it. Yes, it was anticompetetive behavior on Microsoft's part which was responsible. Yes, by all rights Apple should have had an opportunity to compete on a fair playing ground, just like Novell should have had their opportunity. And yes, Microsoft has yet to pay the piper for their past wrongdoing...
MacOS was clearly superior to Windows 3.x. Hell, MacOS 7 was superior to Windows 95/98 in just about every way imaginable. That it was never ported and sold as a product may be a success and notch in Microsoft's belt, but it's one of the best examples of how Microsoft's (mis)behavior hurt consumers, and in so doing damaged the American economy. When your clueless office-mate asks you "how did Microsoft's practices hurt me?" you can point to the MacOS on Intel that never was and say "here's something you might have wanted that Microsoft made damn certain you couldn't get."
I downloaded a copy from the gameaholic site and got a checksum error while running the installation script. I think some of the copies on mirror sites are bad.
They were scheduled for delivery in May -- it's September. Frankly, I think it's pretty lame that the/. community thinks it's cool enough to warrant front page coverage of a Linux game, previously released for Windows over a year ago. Yes, my copy is on order, but I'm frustrated by these delays. On the plus side (for Loki), I own 10 Loki games, so as a "loyal" customer I think I have a right to bitch.:-)
In the past I've owned several PDP-11s (had to chuck 'em because of a move ARRRGH!), (11/03, 11/23+, an 11/34, and an original Hexbus 11 with a wirewrap backplane and 8KW of core. I'm not listing all the Suns, SGIs, HP9000s, and VAXen/Alphas... they're to "modern", all being at least 32 bit.
I love old computers.:-) WRT the MIT flea... it's been slim pickings lately; mostly just old PC's. At least there's plenty of cool HAM radio and various test gear still for sale.
J. Maynard: The two best (most efficient) methods of collecting solar power right now are through farming
Tau Zero: Sorry to burst your bubble, but it is probably the least efficient. Plants grown for seed convert sunlight to seed with an efficiency of around 1%. A cheesy solar-steam engine can easily do 5%, solar cells 15%, good steam engines 20+%.
You're missing an important point: production costs. That is, manufacturing solar cells incurs an energy and materials cost which isn't represented by your line of logic. Plants reproduce on their own, and as such incur only farming, distilling, and transportation costs as a potential fuel; also, they can be grown and distilled locally -- thus removing shipping costs from halfway around the world. As we've recently learned over the last year (even if not because of real scarcity but at the hand of an oil cartel; OPEC), just because oil is cheap today doesn't mean its price won't spike tomorrow... DUH, it's a finite commodity!
Solar steam shows real promise as an alternative electricity generator, along with wind, geothermal, and hydro, but I was discussing alternative liquid fuels -- for automobiles. Unless fuel cells really work out, I don't think current rechargable batteries will supply an electric car revolution with it's energy needs.
Current practice uses petroleum-based insecticides and herbicides, natural-gas-derived nitrate fertilizers and diesel fuel for planting, cultivation and harvest. This isn't sustainable in the least, and the yield from corn looks pretty bad if you count those inputs against the fuel production.
I think you'll find that with hemp and jute it becomes far more feasible. Consider that hemp grows across a wide climate. It grows in fairly dry and arid land, and generates copious vegetable matter. I also note that I buy organic, eat organic, and consider the move to consolidate power over our world's food supply by multination corporations pushing GMOs, pesticides, and synthetic fertilizers puts humanity in great peril. And, of course, that's just one of the ways we could fuck ourselves long term.
I don't dispute your figures in the second paragraph.
And if you are even thinking of solar power, don't bother. Solar cells would have to be 25 times as efficient as they exist now. Putting solar panels atop of your hood, top and trunk would not even yield enough power to go a few miles after several hours of charge. Wind power is in the same boat, although it it is more efficent than solar.
What you say in your post is accurate, however, you miss an important point with this quote. Fossil fuels are simply chemically stored solar energy, which will run out! You're claiming that photovoltaics aren't viable because the energy conversion ratio is poor, while avoiding the fact that the energy we're using right now was culled from the same source over hundreds of millions of years. If we can't figure out how to generate a similar level of energy production without relying on a stored and limited energy suply, as a society we're fucked!
We don't have millions of years to press a huge history of plant matter down into a barrel of oil in order to sustain "the wonderful economy" (though I'd argue that the economy can't be altogether too well off over the long haul if it's ignoring issues which involve our very survival while in a feeding frenzy of over consumption and energy utilization -- some day we'll rue how poorly we managed this resource). But we CAN grow alcohol based fuels, and we CAN use these alchohol based fuels in a sustainable manner; the CO2 released from burning alcohol would be absorbed by the next generation of plants being grown.
From a photovoltaic standpoint, since surface area is the limiting issue why not cover a segment of the ocean -- say at the equator -- with solar cells converting ocean water into stored (and transported) hydrogen? Transmitting electricity generated by solar may not make much sense, but hydrogen is an excellent transport mechanism.
Wide acceptance of low-emissions vehicles is almost completely dependent on the existence of a, for lack of a better word, refueling infrastructure. People don't want to have to drive across town to the one electric recharge station (or hydrogen station, or whatever) when they could drive their combustion car 2 blocks. And they dont' want to run out of whatever fuel they're using out in the middle or nowhere, or in a bad neighborhood, etc.
First of all, many fuel cells can run off of current gasoline/gasohol without modification. So it's possible to move to fuel cells while maintaining our current infrastructure. However, at some point we're going to have to face up to the fact that petrolium reserves are a limited resource. At that point we're going to HAVE to move toward solar based collection, or we'll need fusion. Fission is a no-go because even with all the uranium in the world converted to electrical generation we'd use up our uranium reserves in a few years if we went all nuclear for electricity generation. (see: from Frontline: What's up with the weather?)
We don't need to collect solar energy with photovoltaics. In fact, the two best (most efficient) methods of collecting solar power right now are through farming, and passive solar heat. While growing corn may not be the most efficient plant to farm fuel alcohol, it IS sustainable. If we want to get serious about removing our dependency on a non-sustainable fuel (never mind the foreign policy issues of dependency on foreign oil), HEMP and JUTE are the the most efficient means of doing so. See The North American Industrial Hemp Council and Hemp Lobby.org for an insightful look into what we (as a society) are wasting by preventing farmers from growing industrial hemp for paper, pressboard, fuel alcohol, and fabrics.
You may also be interested in this Eurekalert release Scientists create organic photovoltaic devices to convert light into electricity which discusses the use of ionically self-assembled monolayer process onto a fullerene (bucky tube) surface, which generates a molecule thin organic photovoltaic cell -- without all those nasty solvents used in the traditional process of making the silicon counterpart.
There are real alternatives to implement if we want to get off this crazy dependency on fuel oil. But the real issue is not infrastructure, but politics; as the oil industry has it's hands on our political establishment. Just which of our presidential candidates comes from a family of oil tycoon and has a vice presidential nominee that's a former CEO of a large Texas oil company?
ps - Frankly, Gore's record on the environment is just a bunch of enviro-talk hooey as well. I think they both suck. I'll be voting Nader this time around.
Agreed. I'll be voting Nader as well. I even wrote a letter (and snail mailed it!) to the Commission on Presidential Debates both in protest of their decision to cut Nader and Bucanan out of the Debates, and against their taking corporate donations to pay for them. It's just plain wrong to take donations from corporate organizations that have a vested interest in the outcome of these debates. I think they call that "conflict of interest."
It's because RH-6.x ships with gcc-2.91.x
on
KDE Strikes Back
·
· Score: 1
which has some obnoxious exception handling bugs in the C++ compiler that the KDE folks need fixed. This is understandable.
Unfortunately, to upgrade the compiler requires upgrading one's binutils -- which is a royal pain in the ass. I note that RH7.0 beta ships with GCC-2.96.x and the recent binutils... along with KDE 2.0Beta3. OK!:-)
I'd really like to buy a StongARM system if only I could buy the CPU/MOBO in a standard AT/ATX form factor. Anyone know of a modern ARM based system (short of the now dead Netwinder) which can be had on the cheap and uses commodity parts?
Where are the RH-6.x rpms for Beta4???? .debs???
on
KDE Strikes Back
·
· Score: 2
I notice that Caldera OpenLinux and their Technology (Kernel 2.4) preview as well as Suse have precompiled binaries already available, but this is not so for Redhat-6.x and Debian-2.2. One thing I've noticed about GNOME is that the team makes every effort to support most any platform (including other architectures). I recognize that there was once a tiff between Redhat and the KDE teams, but since there are so many Redhat (and to a smaller extent Debian) users here in the States, that if the KDE team wants significant penetration in the US market they're going to have to provide good support for it's most popular distributions.
I am not biased. I will support KDE if my users request so. But I won't manually compile the tree just to show it off. I think the KDE folks ought to re-think their attitude toward Redhat users and support RH6/7 as a top-teir platform -- one with the potential to attract huge numbers of users down the road. That is the goal, right???
New updater and stuff was handled in a previous post by Ian; no point in re-hashing. Thanks Ian!
As for having ads forced down your throat, as one of the lead developers of the new updater, we haven't heard any plans to put banner ads in the software and we certainly haven't written any code for it. We may well provide commercial channels through the updater, but with our subscription system, you can simply not subscribe to those channels.
#1 OK. I admit that the current updater doesn't present any ads during the updating process, and that I had no basis to reasonably assume that this policy would change. I was simply venting frustration at how difficult it's been to pick apart how the updater works so I could automate the process across a bunch of workstations. For this misrepresentation, I apologize.
#2 Splitting hairs over whether an xml meta-data file is a database or not misses the point... RPM should handle this stuff. That it doesn't only serves to show the limitation of RPM. I see why you need the dependency checks before installation, so this is a non-issue.
Let's bury the hatchet and get back to work on figuring out how to manage large installations of GNOME workstations.:-)
Unfortunately, I'm not about to convince my managers that dumping Redhat for Debian across a whole bunch of systems is worth our trouble. Frankly, I think it IS worth our trouble, because of the stability and security a Debian migration would provide. Hell, if I had my way we'd be dumping Linux for OpenBSD, strictly on security grounds.
Hows that for baiting the RH crowd? (And I even run RH at home -- *cough!* through an OpenBSD NAT server). Use what works.
I'll join both the lists you suggest and download off of ftp.helixcode.com to an internal respository so my desktops don't hit your servers. However, please take my request for better documentation on the Helix web site seriously. I don't want to have to CVSsup Helix-Gnome just so I can poke through your source in order to find the answers I need; at work I have a limited time budget. However, Helix is such a dramatic improvement over October GNOME that I've been planning the deployment in the hopes that this issue gets sorted out before it bites me in the ass down the road. Heh... not smart.:-)
I'm afraid this just isn't true. The current updater uses the rpm database alone, and the next generation updater we demoed at LWE uses either your rpm database or the/var/lib/dpkg/status file, depending on what type of system you are on.
itp: Thank you for your quick response to my post. If there is no secondary database for helix-update, then I ask: how is it that helix-update tool doesn't know if one manually installs a helix update via rpm? I've tried this and then run helix-update to find that the updater doesn't recognize that my previous install with rpm just occurred, and then blindly presents the update as one among the list of available packages. If selected, the updater will then download the package and attempt to install it again. This suggests to me that helix-update is keeping track of what packages it downloads in a separate database from rpm (even though it downloads rpm files and installs them through the rpm tool). I recognize that I may be factually incorrect about this assumption, so please inform me and everyone else how the updater works with written documentation published on your web site.
Second: Where do I download current updates? I notice that not all the mirror sites are in sync with Helix's Akamai site. I'd like to know a URL for exactly where to download current rpm files for helix packages.
I don't expect Helix to write my tool, if that's not in your business model. I DO expect Helix to provide adequate documentation so that I can easily write this tool.
Hello?? Open source?? Write it yourself?? McFly?? Hello??
Hello, yourself. Open Source works best with open documentation. Frankly, this kind of answer not only doesn't solve the problem, it's plain rude.
I can accept if Helix doesn't want to document their installation tools, just don't blame me for choosing another GUI interface. I'll be looking at KDE 2.0 very carefully, comparing it's manageability to GNOME in a large deployment.
Right. Go to that web page and you'll notice that it contains a list of reasons for the updates in plain english, but no links to the actual files! Nor does it provide any documentation on how Helix-update works, where it's database lives, or how to automate the update process. This does NOT solve my problem.
Slashdot Mirror
- Start with an anonymous remailer as described in The Anonymous Remailer FAQ.
- Next, create a NEW PGP key (that's not related to your name, DUH!) and upload it to one of the many PGP Keyring servers, such as at pgp.mit.edu.
- Next, create an internal CVS tree with your source code. Tar it up, split it, md5sum the file, and attach both to a mail message pgp signed with your anonymous key. Mail this to the remailer with a USENET news header of your favorite newsgroup (make certain all your friends know the correct newsgroup to puruse).
- Now, all your friends need only suck down the attachment from the agreed upon USENET newsgroup and create their own CVS trees.
- They all follow the same steps, only they post patches, along with an MD5 sum of the patch+original CVS source tree (tar'd, or individual file)... this way you know when you're applying the patch that it's against a current revision).
There you go, because you're using an anonymous remailer it's completely anonymous. Because everyone is signing the USENET post with their (anonymous) PGP keys it's absolutely certain proof of authenticity from the author, and because you're MD5 suming either the source tree tarball or individual files you can be certain that the patch is against a particular revision of the source tree/file.Answer your question?
It's my understanding (not as a lawyer) that the GPL is more credible constitutionally than shrink wrap licenses is because most of the clauses in a shrink wrap relate to acceptable use rather than restrictions on duplication. For example, many Microsoft shrinkwrap licenses prevent reverse engineering; some prevent transfer to another system; demand multiple payments for the same license under certain circumstances; and indemnify the author from any fitness of function or warranty.
But the GPL is different. The GPL prevents duplication of an intellectual property licensed as such under a few very specific circumstances. Developers must offer source level changes to the recipient of any binary of which they've derived a previous work released under the GPL (meaning their changes must be released under a license which won't conflict with these clauses). Which basically says, "you can't distribute this unless you follow my rules of citation and release the source of your changes to your recipients. If you accept these rules you may copy to your heart's content."
Wanna bet you'll see something like that on your next Microsoft click through license??? I betcha NO!
This is a ridiculous argument on it's face simply because MaxOS X is a completely redesigned OS based on Mach and BSD, not the original MacOS codebase. That Apple isn't (formally) supporting older PowerPC hardware is no surprise, though I bet that getting the core OS to run on most PowerMacs won't be terribly difficult. Look, I've never bought a Mac. The last computer I bought from Apple was a II/e, so don't think I'm biased in Apple's favor -- but I think your argument simply doesn't hold water.
. ..
Um, MacOS 7 didn't do memory protection nor preemptive multitasking, right?
Nor does Windows 3.x, 9x. It doesn't support true preemptive multitasking nor a real memory protection model in order to maintain backward compatibility; everything runs in ring 0. It's true that MacOS 7/8/9 shares these limitations with Microsoft's Win9x/ME brethren. However, MacOS has a far superior interface to Windows (INHO). I'll give but one flagrant example:
Windows 3.x abstracted the filesystem away from users through the use of "Program Groups", which had no relation to the filesystem whatsoever. For this reason, many Windows users never learned basic filesystem concepts, such as directory hierarchies. This model continued in Win9x through the use of the "start" button, even though explorer provided access to the filesystem. To this day I know many Windows users who have NO IDEA what the difference is between a directory and a file, and don't care. This means that when they lose files in the filesystem they have no way to find them again.
MacOS represents the filesystem as a set of folders within folders. Let's not even get into a debate on the superiority of HFS to FAT... filesystem metadata support under HFS is so superior to FAT it's just a joke.
That said, I won't consider buying a Mac until they release OS X. I am a UNIX weenie and have been using UNIX since the '80s. NeXTStep is probably the best operating environment I've ever used.
Finally, even given that your argument were true: how does this change Microsoft's anti-competitive and exclusionary licensing behavior with the hardware integrators. Are you arguing that because Win9x has "preemptive multitasking" that Apple should not have been given entry into the market?
There's nothing stopping developers from forking the FreeQT codebase to create a new Windows based QT. Frankly, I think the Windows port of QT is one of the best advantages of QT over GTK+. Windows support with GTK is still in it's infancy while QT is quite usable.
The way to bring Windows desktop users over to Free Software is to create cross platform Apps which reduce the need for Windows as a base platform in order to create a migration path for users. That means porting the new StarOffice and KOffice to Windows, giving users a chance to feel comfortable with the new environment, and then waiting for the next costly Windows upgrade to convince the users "there's a cheaper way..."
MacOS was clearly superior to Windows 3.x. Hell, MacOS 7 was superior to Windows 95/98 in just about every way imaginable. That it was never ported and sold as a product may be a success and notch in Microsoft's belt, but it's one of the best examples of how Microsoft's (mis)behavior hurt consumers, and in so doing damaged the American economy. When your clueless office-mate asks you "how did Microsoft's practices hurt me?" you can point to the MacOS on Intel that never was and say "here's something you might have wanted that Microsoft made damn certain you couldn't get."
And that's NOT a level playing field...
I downloaded a copy from the gameaholic site and got a checksum error while running the installation script. I think some of the copies on mirror sites are bad.
They were scheduled for delivery in May -- it's September. Frankly, I think it's pretty lame that the /. community thinks it's cool enough to warrant front page coverage of a Linux game, previously released for Windows over a year ago. Yes, my copy is on order, but I'm frustrated by these delays. On the plus side (for Loki), I own 10 Loki games, so as a "loyal" customer I think I have a right to bitch. :-)
- TRS-80 Model I
- An original Apple II (no, not the II+ or
//e)
- Two Commodore 64s
- An Atari 800, 800xl and 1200xl
In the past I've owned several PDP-11s (had to chuck 'em because of a move ARRRGH!), (11/03, 11/23+, an 11/34, and an original Hexbus 11 with a wirewrap backplane and 8KW of core. I'm not listing all the Suns, SGIs, HP9000s, and VAXen/Alphas... they're to "modern", all being at least 32 bit.I love old computers.
Solar steam shows real promise as an alternative electricity generator, along with wind, geothermal, and hydro, but I was discussing alternative liquid fuels -- for automobiles. Unless fuel cells really work out, I don't think current rechargable batteries will supply an electric car revolution with it's energy needs.
I think you'll find that with hemp and jute it becomes far more feasible. Consider that hemp grows across a wide climate. It grows in fairly dry and arid land, and generates copious vegetable matter. I also note that I buy organic, eat organic, and consider the move to consolidate power over our world's food supply by multination corporations pushing GMOs, pesticides, and synthetic fertilizers puts humanity in great peril. And, of course, that's just one of the ways we could fuck ourselves long term.
I don't dispute your figures in the second paragraph.
We don't have millions of years to press a huge history of plant matter down into a barrel of oil in order to sustain "the wonderful economy" (though I'd argue that the economy can't be altogether too well off over the long haul if it's ignoring issues which involve our very survival while in a feeding frenzy of over consumption and energy utilization -- some day we'll rue how poorly we managed this resource). But we CAN grow alcohol based fuels, and we CAN use these alchohol based fuels in a sustainable manner; the CO2 released from burning alcohol would be absorbed by the next generation of plants being grown.
From a photovoltaic standpoint, since surface area is the limiting issue why not cover a segment of the ocean -- say at the equator -- with solar cells converting ocean water into stored (and transported) hydrogen? Transmitting electricity generated by solar may not make much sense, but hydrogen is an excellent transport mechanism.
We don't need to collect solar energy with photovoltaics. In fact, the two best (most efficient) methods of collecting solar power right now are through farming, and passive solar heat. While growing corn may not be the most efficient plant to farm fuel alcohol, it IS sustainable. If we want to get serious about removing our dependency on a non-sustainable fuel (never mind the foreign policy issues of dependency on foreign oil), HEMP and JUTE are the the most efficient means of doing so. See The North American Industrial Hemp Council and Hemp Lobby.org for an insightful look into what we (as a society) are wasting by preventing farmers from growing industrial hemp for paper, pressboard, fuel alcohol, and fabrics.
You may also be interested in this Eurekalert release Scientists create organic photovoltaic devices to convert light into electricity which discusses the use of ionically self-assembled monolayer process onto a fullerene (bucky tube) surface, which generates a molecule thin organic photovoltaic cell -- without all those nasty solvents used in the traditional process of making the silicon counterpart.
There are real alternatives to implement if we want to get off this crazy dependency on fuel oil. But the real issue is not infrastructure, but politics; as the oil industry has it's hands on our political establishment. Just which of our presidential candidates comes from a family of oil tycoon and has a vice presidential nominee that's a former CEO of a large Texas oil company?
ps - Frankly, Gore's record on the environment is just a bunch of enviro-talk hooey as well. I think they both suck. I'll be voting Nader this time around.
Agreed. I'll be voting Nader as well. I even wrote a letter (and snail mailed it!) to the Commission on Presidential Debates both in protest of their decision to cut Nader and Bucanan out of the Debates, and against their taking corporate donations to pay for them. It's just plain wrong to take donations from corporate organizations that have a vested interest in the outcome of these debates. I think they call that "conflict of interest."
which has some obnoxious exception handling bugs in the C++ compiler that the KDE folks need fixed. This is understandable.
:-)
Unfortunately, to upgrade the compiler requires upgrading one's binutils -- which is a royal pain in the ass. I note that RH7.0 beta ships with GCC-2.96.x and the recent binutils... along with KDE 2.0Beta3. OK!
I'd really like to buy a StongARM system if only I could buy the CPU/MOBO in a standard AT/ATX form factor. Anyone know of a modern ARM based system (short of the now dead Netwinder) which can be had on the cheap and uses commodity parts?
I notice that Caldera OpenLinux and their Technology (Kernel 2.4) preview as well as Suse have precompiled binaries already available, but this is not so for Redhat-6.x and Debian-2.2. One thing I've noticed about GNOME is that the team makes every effort to support most any platform (including other architectures). I recognize that there was once a tiff between Redhat and the KDE teams, but since there are so many Redhat (and to a smaller extent Debian) users here in the States, that if the KDE team wants significant penetration in the US market they're going to have to provide good support for it's most popular distributions.
I am not biased. I will support KDE if my users request so. But I won't manually compile the tree just to show it off. I think the KDE folks ought to re-think their attitude toward Redhat users and support RH6/7 as a top-teir platform -- one with the potential to attract huge numbers of users down the road. That is the goal, right???
#1 OK. I admit that the current updater doesn't present any ads during the updating process, and that I had no basis to reasonably assume that this policy would change. I was simply venting frustration at how difficult it's been to pick apart how the updater works so I could automate the process across a bunch of workstations. For this misrepresentation, I apologize.
#2 Splitting hairs over whether an xml meta-data file is a database or not misses the point... RPM should handle this stuff. That it doesn't only serves to show the limitation of RPM. I see why you need the dependency checks before installation, so this is a non-issue.
Let's bury the hatchet and get back to work on figuring out how to manage large installations of GNOME workstations.
Unfortunately, I'm not about to convince my managers that dumping Redhat for Debian across a whole bunch of systems is worth our trouble. Frankly, I think it IS worth our trouble, because of the stability and security a Debian migration would provide. Hell, if I had my way we'd be dumping Linux for OpenBSD, strictly on security grounds.
Hows that for baiting the RH crowd? (And I even run RH at home -- *cough!* through an OpenBSD NAT server). Use what works.
I'm definately using "Reply to This" properly. Time for a bug report!
.
.. .
.
Ian,
:-)
I'll join both the lists you suggest and download off of ftp.helixcode.com to an internal respository so my desktops don't hit your servers. However, please take my request for better documentation on the Helix web site seriously. I don't want to have to CVSsup Helix-Gnome just so I can poke through your source in order to find the answers I need; at work I have a limited time budget. However, Helix is such a dramatic improvement over October GNOME that I've been planning the deployment in the hopes that this issue gets sorted out before it bites me in the ass down the road. Heh... not smart.
itp: Thank you for your quick response to my post. If there is no secondary database for helix-update, then I ask: how is it that helix-update tool doesn't know if one manually installs a helix update via rpm? I've tried this and then run helix-update to find that the updater doesn't recognize that my previous install with rpm just occurred, and then blindly presents the update as one among the list of available packages. If selected, the updater will then download the package and attempt to install it again. This suggests to me that helix-update is keeping track of what packages it downloads in a separate database from rpm (even though it downloads rpm files and installs them through the rpm tool). I recognize that I may be factually incorrect about this assumption, so please inform me and everyone else how the updater works with written documentation published on your web site.
Second: Where do I download current updates? I notice that not all the mirror sites are in sync with Helix's Akamai site. I'd like to know a URL for exactly where to download current rpm files for helix packages.
I don't expect Helix to write my tool, if that's not in your business model. I DO expect Helix to provide adequate documentation so that I can easily write this tool.
.
.
I can accept if Helix doesn't want to document their installation tools, just don't blame me for choosing another GUI interface. I'll be looking at KDE 2.0 very carefully, comparing it's manageability to GNOME in a large deployment.
Right. Go to that web page and you'll notice that it contains a list of reasons for the updates in plain english, but no links to the actual files! Nor does it provide any documentation on how Helix-update works, where it's database lives, or how to automate the update process. This does NOT solve my problem.