I tried a lot of FTP mirrors, there is even one at my university that is really fast but this makes hardly any difference.
I am only connected with a 64kbit ISDN line, this makes things somehow slower but as I said the real reason seems to be the way the description files are downloaded.
Moreover I can't see any reason why YOU would download ALL description files, regardless if I did an update only 1 day before. Why can't YOU simply store those files to speed things up?
Anyway - hopefully things will get better in future versions of YaST.
Thank you for your link to this YOU-Replacement, I will give it a try - but the simple availability of such repacements speak a lot about the quality of the original SuSE Product.
WHAT ??? The SuSE Online Update (YOU) is the worst piece of s*** I've ever seen.
Before downloading the actual packages, first so called package descriptions are downloaded. Although this is a good idea, they download one file with the description for every single available update package. This description downloading - although the sum of the descriptions is less than 1MB, takes around 2 hours now. (At the beginning, when SuSE 8.1 was new, it was fast as there were nearly no updates, now there are hundreds). The reason for this is that the "get" request from the FTP-server takes long to get through.
In SuSE versions 8.0, they seemed to fork the whole YaST for every description download. I had a P-166 running with 128MB RAM, and when downloading the descriptions for 100+ packages, YaST was also forked 100+, that exceeded my 128MB Memory and YOU crashed.
Moreover, in SuSE 8.1, the update was not synced with the rpm database. If you updated a package directly via rpm, YOU would not know it and would download the package once again and even conflict afterwards with the by-hand installed package (!).
Besides YOU, SuSE is really o.k. for me, I like it personally. I hope soooo much that the online update is better in 8.2.
Moreover I hope that one can save his configuration of the installed rpm's into a file, like this was possible in SuSE 8.1. When installing a second machine, I had to select all packages BY HAND rather than simply reading a configuration file. SuSE support told me they will include this feature in a later version.
Very important would also be that the mozilla java-plugin at last works. Konqueror is nice, but a lot of webpages are NOT working with it. Mozilla is far more compatible.
When the vessel approaches a planet, e.g. the moon, it speeds up, then it travels with very high speed around it, like a slingshot - but: When it leaves the orbit, it gets slower again until it reaches the original speed.
You write: "least energy" - so, where does this energy come from?
I can think of getting faster from A to B by doing a flyby near a planet because in between, the vessel accelerates to very high speeds and hence does need less time for the whole distance compared to a trajectory without "a planet in the middle".
I wonder that such projects did not emerge earlier. We experimented with a wireless laser link some time ago. You can have a look at our Laserlink
Well, we just shut the laser on and off and did not modulate, anyway speeds of > 1Gbit should be possible with this simple technology. The problems of this design are the adjustment, free line of sight (weather, insects, birds), eye safety, other light sources (sun!) and a very sensitive receiver circuit.
The maximum range is infinite but it can be limited by the protocol (e.g. Ethernet) due to collision windows.
A fast FP is nice. But this does not matter for the majority of applications. I am no guru but I don't think, FP is that important for database and webservers. The scientific market is quite small, so how would the Itanium be placed?
Well, if I remember it correctly, _the_ OS guru, Tanenbaum, said something like "Linux is obsolete".
Look where we are now.
Dreaming and being idealistic is a good thing: It pushes creativity and motivation.
But do never forget that dreams are subjective. Maybe you can persuade similar thinking folks. But can you convince a world where objectivity rules?
People don't care about superiour and clean designs. They care about speed, price and reliability. And they are right this way. Blaming them on being short-sighted is something that is _really_ obsolete.
Linus never forgot these facts. I think this is one of his biggest strengths.
1) They could never have been sure, that the worm would hit the Internet so intensive. Hence, if they would have screamed "fire", they also could have been very wrong, which would not give them a better reputation.
2) If a virus/worm actually does damage, more people will buy their software.
Both systems have their pros and cons, here are some points to consider (HWR=HardWareRaid, SWR=SoftWareRAID):
- HWR with cheap controllers also stress the CPU as only parts of the RAID-Code is executed on the card. - In HWR, you can only RAID whole disks, not partitions. - HWR controllers need drivers - for some there are no Linux drivers, some are "alpha", some are not included with your favorite distribution etc. - Booting with SWR can be quite tricky - The Firmware of HWR controllers can be buggy - getting a fix is probably not that easy as fixing a bug in Linux SWR. - What happens, if your HWR-Controller fails and you cannot get a replacement? How do you get your data back? This is no problem with SWR. - Hotplugging is probably better supported with HWR solutions. - HWR is not necessarily easier to setup. Managing my Mylex DAC960 was a lot harder than setting up Linux SWR.
I would not say that HWR is the only way to go in production systems. It depends somehow on the application. I think, SWR can be more secure in some way. Probably the performance will not be that good as a $1000.- HWR controller, but maybe it's "enough" performance. Why spend $1000 if you just don't need to?
What about a Linux Firewall? RAID performance is no real issue here - but security for the logfiles is.
What I would really like to see is how Linux SWR performs to various HWR solutions. There are some tests on HWR controllers on Tom's Hardware page, but it seems there are no thorough tests on Linux SWR.
Well, the things he critizises are somehow right. Only the way he does is not helpful - it's more like "bashing" than "helping to improve".
But one thing has to be said: I compiled mplayer for myself and it can now play any video format (except quicktime) I use and it plays it perfectly smooth. The only problem is that the TV-out of my VGA (Matrox G550) is not supported with Linux due to copyright issues, hence I have to switch to Windows when watching films on my TV.
Man, those Windows players are *really* a pain in the a**. The playback is not smooth, the video/audio gets out of sync, the Window Media Player stops decoding when there are errors in the stream, the DivX player notorioulsly crashes my system, the TV-Out is not working for SVGACD's/DVD's, for viewing Divx on the TV-Out you have to install a strange shareware-program, AC3-Audio codecs are sometimes not working; Well - an endless list.
Please note: XML is NOT the holy grail. It *can* be an excellent solution for many problems but it always depends on what and how you do it.
Misunderstanding (1): XML is human readable Yes, it is. (unless it is not compressed with a proprietary protocol which is not so unlikely). But only because you can read it this does not mean you can actually *understand* it. The so called scheme, that makes you understand an XML document can be proprietary and not open. There is no reason to believe that Microsoft XML-Documents will have public available schemes.
Misunderstanding (2): XML is suitable for everything (e.g. configuration files). Simply wrong. It's no fun at all to e.g. edit the/etc/hosts file by hand if it's in an XML style, it's much easier in the current style. Moreover writing a GUI for editing non-XML config files is no big difficulty. Configuration files should be editable by hand (easily) and possibly by a GUI.
To me XML has it's pros but also it's cons.
Microsoft wants us to believe that they converted from "Saulus to Paulus" by using a standardized language that is human readable. But we will all soon recognize that they will still use their proprietary formats to lock everyone out.
Good joke! Probably you have never been to Switzerland, have you? I'm from Austria (near Germany/Switzerland) and know many people who are from Switzerland or work there. All I can say is: BEWARE!
People are quite conservative there, life is very strictly organized and people are very oppressed, far more than in the USA - not by a politician, mereley by themselfes.
Foreign people are mostly unwanted and it's quite complicated to assimilate.
Make yourself a favor and choose a better location.
If you want to know more about life in Switzerland, read books from "Max Frisch", like e.g. "Stiller" - he must have known as he lived there.
In Software RAID the configuration is once stored in/etc/raidtab, what you can easily backup. Moreover it's stored on each disk of the array.
Moreover you forget one important thing: The controller can also fail. If that happens, your configuration is lost. There are controllers that cannot read the configuration from the disk, hence all the data is lost. Moreover if you cannot get the same controller from your vendor, once again all your data is lost as e.g. an ICP-Vortex controller probably cannot read a RAID array built with an Adaptec controller.
Comparison lacks most important features
on
IDE RAID Examined
·
· Score: 1
There are some things I just miss in all these tests. There has already been another IDE-RAID test around that also lacks those important information:
1) As you will notice, at the read tests, RAID0 ist a lot faster than RAID1. This is unclear to me as with RAID1 it is possible to speedup reading by splitting the read requests to 2 disks.
2) In most tests the single disk is faster than RAID5, sometimes it's even faster than RAID0 (!). It would be interesting why this happens, if this is a RAID-specific problem or if the IDE-RAID controller are just so bad. Moreover in some tests single drive ATA-100 is faster than single drive ATA-133, this is completely unclear to me and should be explained in the article.
3) RAID5 with 4 disks would be a lot more interesting thatn RAID0 with 4 disks. Nobody would probably do 4-disk RAID0 with IDE as the risk is far to high that one disk failes and data gets lost.
4) What the article lacks most is a comparison to software RAID (e.g. with Linux.) What I assume is that Linux software RAID will probably be faster than any of these hardware RAID solutions.
5) Moreover what is mostly not considered with Hardware RAID controllers is what to do if the controller fails. I use for one of my Linux servers a SCSI-Controller by DPT (now Adaptec) that works quite well but what should I do if this controller fails? Are those controllers compatible - probably not. So, if the controller fails and if I cannot get a replacement, all data will be lost. This is a BIG PLUS for software RAID.
6) Although it's quite hard to do, a comparison to a hardware SCSI-Controller would have been VERY informative.
It seems many mix up CMOS/CCD.
CMOS and CCD are two different technologies, both have their pros and cons but they should not be mixed up.
AFAIK CMOS technology is not used in digital photography, it is merely used for sensors and similar things.
Re:Hopefully this will mean more free-space optics
on
Wireless Congestion
·
· Score: 1
We did our own design some times ago, if you are interested, have a look at:
http://strike.wu-wien.ac.at/~dusty/projekte/laserl ink/index.shtml
Although solutions like this work and are much faster than 802.11 solutions (100Mbit are no problem), they have the following problems:
- weather dependend
- high precision adjustments
- obstacles (birds, insects) hinder the transmission
They are a lot harder to set up than a simple 802.11 solution, moreover they only work point-to-point.
Anyway, the eye-safety thing is no issue at all as one can easily make a 20mW Laser that reaches > 10km eye-safe with a simple beam expander.
Do-it-yourself designs are probably also possible by the use of transceivers of Micro Linear - but I just can't find time...
Yes, Matrox has Linux drivers for their products. The problem is that they are far from complete. In my case I own a Matrox G550 and there is no way to get the TV-Out running with Linux. Same for G450, only the TV-Out for the G400 works.
The worst thing about this is that Matrox will probably never support the TV-Out with Linux, they even seem to be not interested in this market as they don't answer any questions about this topic in their Matrox forum.
Well, this is indeed a real challenge.
Some time ago we also tried to build a laserlink and succeeded with 128kbit (IrDA). The link was very stable, there was no problem accomplishing a link at around 2km. Next we tried to "upgrade" to 10baseT but sadly never found time to finish this. If anyone is interested, have a look at:
http://strike.wu-wien.ac.at/~dusty/projekte/laserl ink/index.shtml
Slashdot Mirror
I tried a lot of FTP mirrors, there is even one at my university that is really fast but this makes hardly any difference.
I am only connected with a 64kbit ISDN line, this makes things somehow slower but as I said the real reason seems to be the way the description files are downloaded.
Moreover I can't see any reason why YOU would download ALL description files, regardless if I did an update only 1 day before. Why can't YOU simply store those files to speed things up?
Anyway - hopefully things will get better in future versions of YaST.
Thank you for your link to this YOU-Replacement, I will give it a try - but the simple availability of such repacements speak a lot about the quality of the original SuSE Product.
WHAT ???
The SuSE Online Update (YOU) is the worst piece of s*** I've ever seen.
Before downloading the actual packages, first so called package descriptions are downloaded. Although this is a good idea, they download one file with the description for every single available update package. This description downloading - although the sum of the descriptions is less than 1MB, takes around 2 hours now. (At the beginning, when SuSE 8.1 was new, it was fast as there were nearly no updates, now there are hundreds). The reason for this is that the "get" request from the FTP-server takes long to get through.
In SuSE versions 8.0, they seemed to fork the whole YaST for every description download. I had a P-166 running with 128MB RAM, and when downloading the descriptions for 100+ packages, YaST was also forked 100+, that exceeded my 128MB Memory and YOU crashed.
Moreover, in SuSE 8.1, the update was not synced with the rpm database. If you updated a package directly via rpm, YOU would not know it and would download the package once again and even conflict afterwards with the by-hand installed package (!).
Besides YOU, SuSE is really o.k. for me, I like it personally. I hope soooo much that the online update is better in 8.2.
Moreover I hope that one can save his configuration of the installed rpm's into a file, like this was possible in SuSE 8.1. When installing a second machine, I had to select all packages BY HAND rather than simply reading a configuration file. SuSE support told me they will include this feature in a later version.
Very important would also be that the mozilla java-plugin at last works. Konqueror is nice, but a lot of webpages are NOT working with it. Mozilla is far more compatible.
When the vessel approaches a planet, e.g. the moon, it speeds up, then it travels with very high speed around it, like a slingshot - but: When it leaves the orbit, it gets slower again until it reaches the original speed.
You write: "least energy" - so, where does this energy come from?
I can think of getting faster from A to B by doing
a flyby near a planet because in between, the vessel accelerates to very high speeds and hence does need less time for the whole distance compared to a trajectory without "a planet in the middle".
Or am I missing something?
Hmmm, what about OS-X by Apple? OS-X heavily relies on BSD. And AFAIK OS-X is gaining more and more users.
Well, we just shut the laser on and off and did not modulate, anyway speeds of > 1Gbit should be possible with this simple technology. The problems of this design are the adjustment, free line of sight (weather, insects, birds), eye safety, other light sources (sun!) and a very sensitive receiver circuit.
The maximum range is infinite but it can be limited by the protocol (e.g. Ethernet) due to collision windows.
A fast FP is nice. But this does not matter for the majority of applications. I am no guru but I don't think, FP is that important for database and webservers. The scientific market is quite small, so how would the Itanium be placed?
Well, if I remember it correctly, _the_ OS guru, Tanenbaum, said something like "Linux is obsolete".
Look where we are now.
Dreaming and being idealistic is a good thing: It pushes creativity and motivation.
But do never forget that dreams are subjective. Maybe you can persuade similar thinking folks. But can you convince a world where objectivity rules?
People don't care about superiour and clean designs. They care about speed, price and reliability. And they are right this way. Blaming them on being short-sighted is something that is _really_ obsolete.
Linus never forgot these facts. I think this is one of his biggest strengths.
You are right in this case. So this Firewall is indeed a bad example - but there are probably other applications where software RAID is suitable.
Two more points to your posting:
1) They could never have been sure, that the worm would hit the Internet so intensive. Hence, if they would have screamed "fire", they also could have been very wrong, which would not give them a better reputation.
2) If a virus/worm actually does damage, more people will buy their software.
Strange, that you have so much troubles with FTP behind a firewall.
Recently, I set up a Linux IPTables firewall for a customer, who had a Windows ftp server he wanted to connect.
I just did a portforwarding of port 21, loaded the ftp-firewall modules and it worked.
With stateful firewalls, that have protocol helpers, such things should be quite easy so set up.
Both systems have their pros and cons, here are some points to consider (HWR=HardWareRaid, SWR=SoftWareRAID):
- HWR with cheap controllers also stress the CPU as only parts of the RAID-Code is executed on the card.
- In HWR, you can only RAID whole disks, not partitions.
- HWR controllers need drivers - for some there are no Linux drivers, some are "alpha", some are not included with your favorite distribution etc.
- Booting with SWR can be quite tricky
- The Firmware of HWR controllers can be buggy - getting a fix is probably not that easy as fixing a bug in Linux SWR.
- What happens, if your HWR-Controller fails and you cannot get a replacement? How do you get your data back? This is no problem with SWR.
- Hotplugging is probably better supported with HWR solutions.
- HWR is not necessarily easier to setup. Managing my Mylex DAC960 was a lot harder than setting up Linux SWR.
I would not say that HWR is the only way to go in production systems. It depends somehow on the application. I think, SWR can be more secure in some way. Probably the performance will not be that good as a $1000.- HWR controller, but maybe it's "enough" performance. Why spend $1000 if you just don't need to?
What about a Linux Firewall? RAID performance is no real issue here - but security for the logfiles is.
What I would really like to see is how Linux SWR performs to various HWR solutions. There are some tests on HWR controllers on Tom's Hardware page, but it seems there are no thorough tests on Linux SWR.
It is real, have a look at:
This location.
Pretty interesting.
Well, the things he critizises are somehow right. Only the way he does is not helpful - it's more like "bashing" than "helping to improve".
But one thing has to be said:
I compiled mplayer for myself and it can now play any video format (except quicktime) I use and it plays it perfectly smooth. The only problem is that the TV-out of my VGA (Matrox G550) is not supported with Linux due to copyright issues, hence I have to switch to Windows when watching films on my TV.
Man, those Windows players are *really* a pain in the a**. The playback is not smooth, the video/audio gets out of sync, the Window Media Player stops decoding when there are errors in the stream, the DivX player notorioulsly crashes my system, the TV-Out is not working for SVGACD's/DVD's, for viewing Divx on the TV-Out you have to install a strange shareware-program, AC3-Audio codecs are sometimes not working; Well - an endless list.
I'm soooo happy to have MPlayer under Linux!
Please note: XML is NOT the holy grail.
/etc/hosts file by hand if it's in an XML style, it's much easier in the current style. Moreover writing a GUI for editing non-XML config files is no big difficulty. Configuration files should be editable by hand (easily) and possibly by a GUI.
It *can* be an excellent solution for many problems but it always depends on what and how you do it.
Misunderstanding (1): XML is human readable
Yes, it is. (unless it is not compressed with a proprietary protocol which is not so unlikely). But only because you can read it this does not mean you can actually *understand* it. The so called scheme, that makes you understand an XML document can be proprietary and not open. There is no reason to believe that Microsoft XML-Documents will have public available schemes.
Misunderstanding (2): XML is suitable for everything (e.g. configuration files).
Simply wrong. It's no fun at all to e.g. edit the
To me XML has it's pros but also it's cons.
Microsoft wants us to believe that they converted from "Saulus to Paulus" by using a standardized language that is human readable. But we will all soon recognize that they will still use their proprietary formats to lock everyone out.
Good joke!
Probably you have never been to Switzerland, have you? I'm from Austria (near Germany/Switzerland) and know many people who are from Switzerland or work there. All I can say is: BEWARE!
People are quite conservative there, life is very strictly organized and people are very oppressed, far more than in the USA - not by a politician, mereley by themselfes.
Foreign people are mostly unwanted and it's quite complicated to assimilate.
Make yourself a favor and choose a better location.
If you want to know more about life in Switzerland, read books from "Max Frisch", like e.g. "Stiller" - he must have known as he lived there.
Sorry, that's to shortsighted:
/etc/raidtab, what you can easily backup. Moreover it's stored on each disk of the array.
In Software RAID the configuration is once stored in
Moreover you forget one important thing:
The controller can also fail. If that happens, your configuration is lost. There are controllers that cannot read the configuration from the disk, hence all the data is lost.
Moreover if you cannot get the same controller from your vendor, once again all your data is lost as e.g. an ICP-Vortex controller probably cannot read a RAID array built with an Adaptec controller.
There are some things I just miss in all these tests. There has already been another IDE-RAID test around that also lacks those important information:
1) As you will notice, at the read tests, RAID0 ist a lot faster than RAID1. This is unclear to me as with RAID1 it is possible to speedup reading by splitting the read requests to 2 disks.
2) In most tests the single disk is faster than RAID5, sometimes it's even faster than RAID0 (!). It would be interesting why this happens, if this is a RAID-specific problem or if the IDE-RAID controller are just so bad. Moreover in some tests single drive ATA-100 is faster than single drive ATA-133, this is completely unclear to me and should be explained in the article.
3) RAID5 with 4 disks would be a lot more interesting thatn RAID0 with 4 disks. Nobody would probably do 4-disk RAID0 with IDE as the risk is far to high that one disk failes and data gets lost.
4) What the article lacks most is a comparison to software RAID (e.g. with Linux.) What I assume is that Linux software RAID will probably be faster than any of these hardware RAID solutions.
5) Moreover what is mostly not considered with Hardware RAID controllers is what to do if the controller fails. I use for one of my Linux servers a SCSI-Controller by DPT (now Adaptec) that works quite well but what should I do if this controller fails? Are those controllers compatible - probably not. So, if the controller fails and if I cannot get a replacement, all data will be lost. This is a BIG PLUS for software RAID.
6) Although it's quite hard to do, a comparison to a hardware SCSI-Controller would have been VERY informative.
It seems many mix up CMOS/CCD. CMOS and CCD are two different technologies, both have their pros and cons but they should not be mixed up. AFAIK CMOS technology is not used in digital photography, it is merely used for sensors and similar things.
We did our own design some times ago, if you are interested, have a look at: http://strike.wu-wien.ac.at/~dusty/projekte/laserl ink/index.shtml
Although solutions like this work and are much faster than 802.11 solutions (100Mbit are no problem), they have the following problems:
- weather dependend
- high precision adjustments
- obstacles (birds, insects) hinder the transmission
They are a lot harder to set up than a simple 802.11 solution, moreover they only work point-to-point.
Anyway, the eye-safety thing is no issue at all as one can easily make a 20mW Laser that reaches > 10km eye-safe with a simple beam expander.
Do-it-yourself designs are probably also possible by the use of transceivers of Micro Linear - but I just can't find time...
Yes, Matrox has Linux drivers for their products. The problem is that they are far from complete. In my case I own a Matrox G550 and there is no way to get the TV-Out running with Linux. Same for G450, only the TV-Out for the G400 works. The worst thing about this is that Matrox will probably never support the TV-Out with Linux, they even seem to be not interested in this market as they don't answer any questions about this topic in their Matrox forum.
Well, this is indeed a real challenge. Some time ago we also tried to build a laserlink and succeeded with 128kbit (IrDA). The link was very stable, there was no problem accomplishing a link at around 2km. Next we tried to "upgrade" to 10baseT but sadly never found time to finish this. If anyone is interested, have a look at: http://strike.wu-wien.ac.at/~dusty/projekte/laserl ink/index.shtml