Sounds like you had some bad burns. While I agree that the installer should provide the option to skip a failed rpm install if its not critical, I hardly see how you can blame Fedora for your own problems with your media. If the CDs were commercial pressed ones, then I think you'd have a claim against the company. But since you burned your own and never bothered to verify each disk (your drive could have been dirty too or your burn was too fast for your drive), you can't blame Fedora's team.
If I was a developer I could learn only one thing from your non-bug report. The installer should fail rpm installs more gracefully. "It sucks" doesn't prove anything.
Fedora Core 2 has proved to be rather nice on my workstations. I look forward to Fedora Core 3.
Re:jsp is a bad idea, but Java is not
on
On PHP and Scaling
·
· Score: 1
Personally I really dislike struts. It serves its purpose when you are working within the JSP framework. But ditching JSP entirely is a great thing. That's what tapestry does.
Re:jsp is a bad idea, but Java is not
on
On PHP and Scaling
·
· Score: 4, Interesting
Even better than JSP and other technologies is to use Jakarta's Tapestry as the presentation layer. Tapestry rocks and I look forward to having something like that on PHP. Right now PHPTal is close. The ability to define a page as components (almost in GUI terms) and then define event call-backs and so forth really makes life better.
Tapestry for the view, Spring for the control, and Hibernate for the model is a combination hard to beat with php. Sooner or later all these technologies will be used no matter what underlying language.
How much is java used in OpenOffice? OpenOffice is all C++ as far as I know, except that you can use Java to extend it and control it. I've heard several people complain about how slow OpenOffice is and blaim it on Java, which is ignorant since it is written in C++.
Eclipse is an example of a successful Java program. And with SWT and GTK and other GUI bindings, I see no reason for it not to be more widely used. That said, I think we'll see a lot more mono (C#)-based GTK apps on linux than java in the near future.
There is a version of OpenOffice called NeoOffice/J that uses java to do the rendering, thus eliminating the dependence on X11. However this is a not a native-looking app. It still looks exactly like the X11 version, but runs without X11. So it's not ideal, but it works.
The SwingWT project gives you the best of both worlds for developing your Java GUIs. It's an in-progress implementation of the Swing and AWT apis using SWT to draw the widgets. Looks much, much better than Swing, but still lets you use the nice API that many developers like. And for platforms where SWT isn't running, you can go back to the normal Swing classes. Java 1.5's Swing is supposed to be much more themeable and support anti-aliased fonts, so that will mitigate a lot of Swing's ugliness.
Look at Apple's Xserve RAID
on
SATA vs ATA?
·
· Score: 2, Insightful
Apple's XServer RAID solution seems to be one of the cheapest dollar per gigabyte solution that I've ever seen. They use fast ATA drives. Although ATA drives can have problems, Apple uses only the best drives from each lot (hence they are a bit more expensive than if you bought the disks from a jobber). The RAID is a true hardware raid, allowing the creation of a hot-spare, e-mail notification, etc. The configuration software is java and runs on any platform. The RAID unit itself is fibre channel, so it can hook to servers running any OS and looks just like a big scsi disk. We have our arrays set up such that we're mirroring 2 phyiscally sparate arrays together (each raid 5+ hot spare), so we can lose up to 4 disks wihout any loss of data. Each array is about 2 or 3 raw terrabytes.
I would avoid the other controller cards you mentioned for the reasons the other posters mentioned. The Xserve RAID is all the benifits of a good scsi backplane (RAID, monitoring, etc) for a fraction of the cost.
Unfortunately the way windows updates work makes this solution very unworkable. Unless you make new images after every update (and if that screws it up that would defeat the purposes of an image wouldn't it), if you machine does get hosed (by spyware or some virus) and then you restore to a good image that's missing the latest patches, you're vulnerable to pick up the same problems all over again.
Windows is a real liability, that's for sure, no matter how you look at it.
Austrialia used to have paper money? That's strange. No currency I know of has been printed on paper for many years. Most are currently printed on some kind of cloth (such as cotton). While the wear characteristics of cotton are nowhere near as good as plastic, I have washed many bills in the washing machine (some on purpose) and they come out great. In fact, after ironing, they often are almost as crisp as brand new bills.
Capslock is useful for touch typists, However it would probably be best if it worked as it did in the old days: Pressing capslock puts the keyboard into upper case until the shift key is pressed. Then it should go off.
If 'local' can have 5 letters, would it be so deadly to spell out 'user'?
Umm,/usr does *not* stand for "user." It stands for "Unix System Resoures."
By the way all the 2 and 3 letter commands came from at&t and the longer commands came from Berkeley (or the other way around).
Re:They should stick with C
on
The GNOME Roadmap
·
· Score: 4, Insightful
I think both java and C# have a huge place in Gnome app development. As an example of an impressive app (that's pretty speedy) written for gtk in java, see Azureus. Eclipse is another app written in java that really rocks. Both are speedy, probably as fast as they would be if written in C or C++.
The few C# gtk/gnome apps I've seen look great too. Just like the transition to enterprise frameworks like j2ee is the only sustainable way to do large-scale web development, using C# or java or some other tool is the only way to sustain large-scale client application development in the long run. Sure you can do it in C or C++, but sooner or layer the maintenance issues will get really expensive.
I distinctly remember reading on their site about the various ways that they could go about emulating windows. They mentioned wine but then said that wine was a fundementally flawed idea and that it would actually bring instability to linux. They definitely tried to make it appear like they were doing something better than wine. Then to find out they are using wine, while fine in and of itself, made me feel like they were being untruthful (or at least not forthcoming) about where their code was really coming from.
Codeweavers is in a far better position to market wine as a product. They'll do ok. I still can't see this Project David really going anyway.
I've tried two different brands of these things and they don't work worth anything. Maybe the expensive Bose one works, but the ones I tried just added a low-pass filter to the signal. No noise reduction at all. It just fools you into thinking that (one type of noise masks another). Besides all this, both pairs I tried were terribly unconfortable. Not to mention the sound quality was lousy. I only used my last pair for 30 minutes on an overseas flight before giving up on the whole idea.
Get earplugs from a local gun store. They work the best.
Maybe someday when I can get real noise-reduction headphones if they are under 200 dollars.
Better yet, maybe it would be better to cancel airplane noise int he cabin itself through some kind of in-plane noise reduction system.
And oh, completely offtopic -- what's the deal with saying, work fine in OOorg -- shouldn't that be works fine with OO? Why the org/.org thingy?
Because the name of the program is "OpenOffice.org." See www.openoffice.org for the reason why this is so (something about another project called OpenOffice).
No. We didn't own the crop anyway. It was under contract for the seed company. So any legal issues are their concern. Besides in the court case, the farmer noticed the volunteer crop growing, recognized that it was the monsanto variety, and purposely bred it.
In the case of our crop, the gene was present in 20% of the sample, but that doesn't mean it was being expressed (or that it would be expressed in the next generation). But this gene, combined with other factors (poor growing season) disqualified the crop as seed, so it was a bit of a loss for us.
Actually the genes do spread by themselves. Recently we grew a couple of hundred acres of special GMO seed canola (from a different company). When the seed we grew was tested, it was found that the monsanto gene was present in almost 20% of the sample. Bear in mind this is from a cross of 2 pure non-monsanto canola varieties. The Monsanto canola has been grown in our area, but it was over 5 miles away and almost 5 years previous. Yet the gene still persisted somehow. So yes, the genes can move by themselves.
Electric vehicles are all fine and good, except that until we have a good clean source of electricity, a proliferation of electric-powered vehicles will actually increase air polution. For example, in Alberta Canada, a study was done to determine the effects on the environment of government-mandated electric cars. The study found the air pollution would increase dramatically as all of Alberta's power plants (well most of them) are coal-fire plants.
This is not to say it's not a good thing but it's certainly not a panacea at this point. Something else to remember is that internal combustion does not necessarily equal bad since practically all energy generation involves combustion in some form or another. For example, burning natural oils (vegatable oil) is environmentally neutral, since there is no net-increase of carbon in the atmosphere (which means no green-house effects).
The problem is that most alternative fuels such as hydrogen and methane come from burning fossil fuels. Although they burn clean in our engines, they've already caused pollution before we even get them in our cars! This fact combined with the fact that alternative fuels simply don't have as many joules of energy per unit as conventional fuels makes alternative fuels less attractive.
If we can get a cleans supply of electricity (from the sun, for example), then all of my points become moot.
In a perfect world, Kerberos is the way to go. Your kerberos ticket would, according to the access controls on each box, grant login and root privileges. SSH can pass along your ticket, granting you seamless access with your credentials.
In practice, Kerberos is really hard to do right and so far ssh support is very weak. But if everything was kerberized (this is in the works), then everything from logins to web access can go through your ticket. Granting root privileges is merely a matter of setting the acl properly and then letting the use ksudo.
Not only is it a ripoff of WINE, in their FAQs on their site they claim that WINE has too many problems to be viable as since WINE implements the win32 API that it makes all of Linux unstable. Somehow their mythical David project was supposed to do it the right way and not have any the problems that Wine had.
One of the few companies that has years of experience with dynamic recompiling emulation is ardi (www.ardi.com). Their 68k synthetic cpu was worked on for several years, achieving incredible performance, but alas, only 1/3 cpu speed on average. See http://www.ardi.com/SynPaper/node12.html.
Now of course in theory if you had a lot of cache you could approach native cpu speeds, assuming that you always executed the same code over and over again. Caching certainly is the key to performance here, just like in CPUS. But realistically, you can't always keep every dynamic block in cache. Eventually it will be invalidated and new blocks will have to be translated. Much faster than emulation (orders of magnitude) but still not quite full host cpu speed.
Your point about translating the assembly code is an interesting point, but fails to account for the fact that this has to happen on the fly. Thus the 1/3 bound is not theoretical, but simply a practical one. I'm sure newer techniques will come along to improve this.
Not quite. While qemu will most likely yet gain virtualization to speed it up, qemu is definitely not what the poster is asking about. qemu is an emulator just like bochs, except that qemu employs dynamic translation of cpu instructions (and caching of said blocks of code). One mode of qemu, qemu-fast, uses a linux kernel module to allow the native OS memory manangement and paging routines. In pure emulation mode memory management is also emulated. At best qemu can yield a raw cpu speed of 1/3 the host processor. Compare this to vmware which, although it seems slow, in theory can be almost full speed in terms of cpu-bound metrics.
I think that down the road qemu will adopt some virtualization techniques on various platforms. Obviously this would be limited to x86 on x86 or ppc on ppc. But it will be exciting to watch and follow qemu. I already run win2k in qemu on my 1.5 gHz athlon at quite a respectable speed.
The FGLRX proprietary drivers do me absolutely no good on my non-x86 linux boxes. In other words the binary-only proprietary drivers may as well be no drivers at all to me. NVIDIA is even worse in this regard. For example my powerbook can't do any suspend or screen dimming because NVIDIA won't even release the specs on how to reset the chipset. It's a lose-lose situation. And unfortunately it's not going to get any better. Like another poster said, my next workstation (not a gaming platform) will be a Radeon 9200 that can be supported by the open source drivers.
Our university library looked into buying a couple of laser-turntables for the purpose of digitizing our vast LP collection. Turns out they are way too expensive to be reasonable right now, and also because they are so accurate they produce way too much noise (much more noise than a conventional needle). The computer scientist in me says that's okay because you can clean up the noise digitally, but in the end they chose to buy some really high-quality needle-tipped turntables.
Someday if we can get players for old LPs that don't use a needle (either laser or image scanner with a good noise-reduction system), I think there would actually be a consumer market for them. Many of us have stacks of old LPs that we would still play if we could (without damaging them further). Many LP recordings apparently having higher-quality sound than CDs (apparently that's not hard) and quadrophonic sound.
Slashdot Mirror
Sounds like you had some bad burns. While I agree that the installer should provide the option to skip a failed rpm install if its not critical, I hardly see how you can blame Fedora for your own problems with your media. If the CDs were commercial pressed ones, then I think you'd have a claim against the company. But since you burned your own and never bothered to verify each disk (your drive could have been dirty too or your burn was too fast for your drive), you can't blame Fedora's team.
If I was a developer I could learn only one thing from your non-bug report. The installer should fail rpm installs more gracefully. "It sucks" doesn't prove anything.
Fedora Core 2 has proved to be rather nice on my workstations. I look forward to Fedora Core 3.
Personally I really dislike struts. It serves its purpose when you are working within the JSP framework. But ditching JSP entirely is a great thing. That's what tapestry does.
Even better than JSP and other technologies is to use Jakarta's Tapestry as the presentation layer. Tapestry rocks and I look forward to having something like that on PHP. Right now PHPTal is close. The ability to define a page as components (almost in GUI terms) and then define event call-backs and so forth really makes life better.
Tapestry for the view, Spring for the control, and Hibernate for the model is a combination hard to beat with php. Sooner or later all these technologies will be used no matter what underlying language.
How much is java used in OpenOffice? OpenOffice is all C++ as far as I know, except that you can use Java to extend it and control it. I've heard several people complain about how slow OpenOffice is and blaim it on Java, which is ignorant since it is written in C++.
Eclipse is an example of a successful Java program. And with SWT and GTK and other GUI bindings, I see no reason for it not to be more widely used. That said, I think we'll see a lot more mono (C#)-based GTK apps on linux than java in the near future.
There is a version of OpenOffice called NeoOffice/J that uses java to do the rendering, thus eliminating the dependence on X11. However this is a not a native-looking app. It still looks exactly like the X11 version, but runs without X11. So it's not ideal, but it works.
The SwingWT project gives you the best of both worlds for developing your Java GUIs. It's an in-progress implementation of the Swing and AWT apis using SWT to draw the widgets. Looks much, much better than Swing, but still lets you use the nice API that many developers like. And for platforms where SWT isn't running, you can go back to the normal Swing classes. Java 1.5's Swing is supposed to be much more themeable and support anti-aliased fonts, so that will mitigate a lot of Swing's ugliness.
Apple's XServer RAID solution seems to be one of the cheapest dollar per gigabyte solution that I've ever seen. They use fast ATA drives. Although ATA drives can have problems, Apple uses only the best drives from each lot (hence they are a bit more expensive than if you bought the disks from a jobber). The RAID is a true hardware raid, allowing the creation of a hot-spare, e-mail notification, etc. The configuration software is java and runs on any platform. The RAID unit itself is fibre channel, so it can hook to servers running any OS and looks just like a big scsi disk. We have our arrays set up such that we're mirroring 2 phyiscally sparate arrays together (each raid 5+ hot spare), so we can lose up to 4 disks wihout any loss of data. Each array is about 2 or 3 raw terrabytes.
I would avoid the other controller cards you mentioned for the reasons the other posters mentioned. The Xserve RAID is all the benifits of a good scsi backplane (RAID, monitoring, etc) for a fraction of the cost.
Unfortunately the way windows updates work makes this solution very unworkable. Unless you make new images after every update (and if that screws it up that would defeat the purposes of an image wouldn't it), if you machine does get hosed (by spyware or some virus) and then you restore to a good image that's missing the latest patches, you're vulnerable to pick up the same problems all over again.
Windows is a real liability, that's for sure, no matter how you look at it.
Austrialia used to have paper money? That's strange. No currency I know of has been printed on paper for many years. Most are currently printed on some kind of cloth (such as cotton). While the wear characteristics of cotton are nowhere near as good as plastic, I have washed many bills in the washing machine (some on purpose) and they come out great. In fact, after ironing, they often are almost as crisp as brand new bills.
Capslock is useful for touch typists, However it would probably be best if it worked as it did in the old days: Pressing capslock puts the keyboard into upper case until the shift key is pressed. Then it should go off.
Umm,
By the way all the 2 and 3 letter commands came from at&t and the longer commands came from Berkeley (or the other way around).
I think both java and C# have a huge place in Gnome app development. As an example of an impressive app (that's pretty speedy) written for gtk in java, see Azureus. Eclipse is another app written in java that really rocks. Both are speedy, probably as fast as they would be if written in C or C++.
The few C# gtk/gnome apps I've seen look great too. Just like the transition to enterprise frameworks like j2ee is the only sustainable way to do large-scale web development, using C# or java or some other tool is the only way to sustain large-scale client application development in the long run. Sure you can do it in C or C++, but sooner or layer the maintenance issues will get really expensive.
I distinctly remember reading on their site about the various ways that they could go about emulating windows. They mentioned wine but then said that wine was a fundementally flawed idea and that it would actually bring instability to linux. They definitely tried to make it appear like they were doing something better than wine. Then to find out they are using wine, while fine in and of itself, made me feel like they were being untruthful (or at least not forthcoming) about where their code was really coming from.
Codeweavers is in a far better position to market wine as a product. They'll do ok. I still can't see this Project David really going anyway.
I've tried two different brands of these things and they don't work worth anything. Maybe the expensive Bose one works, but the ones I tried just added a low-pass filter to the signal. No noise reduction at all. It just fools you into thinking that (one type of noise masks another). Besides all this, both pairs I tried were terribly unconfortable. Not to mention the sound quality was lousy. I only used my last pair for 30 minutes on an overseas flight before giving up on the whole idea.
Get earplugs from a local gun store. They work the best.
Maybe someday when I can get real noise-reduction headphones if they are under 200 dollars.
Better yet, maybe it would be better to cancel airplane noise int he cabin itself through some kind of in-plane noise reduction system.
Because the name of the program is "OpenOffice.org." See www.openoffice.org for the reason why this is so (something about another project called OpenOffice).
Hence the abbreviation, OO.org.
No. We didn't own the crop anyway. It was under contract for the seed company. So any legal issues are their concern. Besides in the court case, the farmer noticed the volunteer crop growing, recognized that it was the monsanto variety, and purposely bred it.
In the case of our crop, the gene was present in 20% of the sample, but that doesn't mean it was being expressed (or that it would be expressed in the next generation). But this gene, combined with other factors (poor growing season) disqualified the crop as seed, so it was a bit of a loss for us.
Actually the genes do spread by themselves. Recently we grew a couple of hundred acres of special GMO seed canola (from a different company). When the seed we grew was tested, it was found that the monsanto gene was present in almost 20% of the sample. Bear in mind this is from a cross of 2 pure non-monsanto canola varieties. The Monsanto canola has been grown in our area, but it was over 5 miles away and almost 5 years previous. Yet the gene still persisted somehow. So yes, the genes can move by themselves.
Why not build yourself a darwin-target cross compiler for your linux machine: http://apple.slashdot.org/article.pl?sid=04/04/22/ 1750204&mode=flat&tid=106&tid=126&tid=156&tid=179& tid=185&tid=190
Electric vehicles are all fine and good, except that until we have a good clean source of electricity, a proliferation of electric-powered vehicles will actually increase air polution. For example, in Alberta Canada, a study was done to determine the effects on the environment of government-mandated electric cars. The study found the air pollution would increase dramatically as all of Alberta's power plants (well most of them) are coal-fire plants.
This is not to say it's not a good thing but it's certainly not a panacea at this point. Something else to remember is that internal combustion does not necessarily equal bad since practically all energy generation involves combustion in some form or another. For example, burning natural oils (vegatable oil) is environmentally neutral, since there is no net-increase of carbon in the atmosphere (which means no green-house effects).
The problem is that most alternative fuels such as hydrogen and methane come from burning fossil fuels. Although they burn clean in our engines, they've already caused pollution before we even get them in our cars! This fact combined with the fact that alternative fuels simply don't have as many joules of energy per unit as conventional fuels makes alternative fuels less attractive.
If we can get a cleans supply of electricity (from the sun, for example), then all of my points become moot.
In a perfect world, Kerberos is the way to go. Your kerberos ticket would, according to the access controls on each box, grant login and root privileges. SSH can pass along your ticket, granting you seamless access with your credentials.
In practice, Kerberos is really hard to do right and so far ssh support is very weak. But if everything was kerberized (this is in the works), then everything from logins to web access can go through your ticket. Granting root privileges is merely a matter of setting the acl properly and then letting the use ksudo.
Not only is it a ripoff of WINE, in their FAQs on their site they claim that WINE has too many problems to be viable as since WINE implements the win32 API that it makes all of Linux unstable. Somehow their mythical David project was supposed to do it the right way and not have any the problems that Wine had.
One of the few companies that has years of experience with dynamic recompiling emulation is ardi (www.ardi.com). Their 68k synthetic cpu was worked on for several years, achieving incredible performance, but alas, only 1/3 cpu speed on average. See http://www.ardi.com/SynPaper/node12.html.
Now of course in theory if you had a lot of cache you could approach native cpu speeds, assuming that you always executed the same code over and over again. Caching certainly is the key to performance here, just like in CPUS. But realistically, you can't always keep every dynamic block in cache. Eventually it will be invalidated and new blocks will have to be translated. Much faster than emulation (orders of magnitude) but still not quite full host cpu speed.
Your point about translating the assembly code is an interesting point, but fails to account for the fact that this has to happen on the fly. Thus the 1/3 bound is not theoretical, but simply a practical one. I'm sure newer techniques will come along to improve this.
Not quite. While qemu will most likely yet gain virtualization to speed it up, qemu is definitely not what the poster is asking about. qemu is an emulator just like bochs, except that qemu employs dynamic translation of cpu instructions (and caching of said blocks of code). One mode of qemu, qemu-fast, uses a linux kernel module to allow the native OS memory manangement and paging routines. In pure emulation mode memory management is also emulated. At best qemu can yield a raw cpu speed of 1/3 the host processor. Compare this to vmware which, although it seems slow, in theory can be almost full speed in terms of cpu-bound metrics.
I think that down the road qemu will adopt some virtualization techniques on various platforms. Obviously this would be limited to x86 on x86 or ppc on ppc. But it will be exciting to watch and follow qemu. I already run win2k in qemu on my 1.5 gHz athlon at quite a respectable speed.
The FGLRX proprietary drivers do me absolutely no good on my non-x86 linux boxes. In other words the binary-only proprietary drivers may as well be no drivers at all to me. NVIDIA is even worse in this regard. For example my powerbook can't do any suspend or screen dimming because NVIDIA won't even release the specs on how to reset the chipset. It's a lose-lose situation. And unfortunately it's not going to get any better. Like another poster said, my next workstation (not a gaming platform) will be a Radeon 9200 that can be supported by the open source drivers.
Our university library looked into buying a couple of laser-turntables for the purpose of digitizing our vast LP collection. Turns out they are way too expensive to be reasonable right now, and also because they are so accurate they produce way too much noise (much more noise than a conventional needle). The computer scientist in me says that's okay because you can clean up the noise digitally, but in the end they chose to buy some really high-quality needle-tipped turntables.
Someday if we can get players for old LPs that don't use a needle (either laser or image scanner with a good noise-reduction system), I think there would actually be a consumer market for them. Many of us have stacks of old LPs that we would still play if we could (without damaging them further). Many LP recordings apparently having higher-quality sound than CDs (apparently that's not hard) and quadrophonic sound.