Your idea isn't new. A german inventor had something like that worked out about five years ago, they are finally through the patenting process and are starting to produce actual hardware. Check out www.dirc.net. Unfortunately the original idea "user buys equipment once, no further costs" has been dropped in the process. Now the business model is more along the lines of "provider buys lots of them and rents them out to consumers". But still pretty cool tech.
Actually, shifting a color value by some bits to the right _is_ the correct way to convert to lower bit resolution (each color component independently, of course). If you were to take the remaining bits into account (maybe rounding up by 1 if the next bit is 1), you'd get a problem. what would you round 0xffffff to? The only problem is that there are different mappings for pictures and bgcolor (probably one of them gets it right, one wrong). That's a plain old bug that needs to be fixed, nothing to be worked around. You can use the lower bits only when dithering, not when choosing the best approximation for a single color.
30% of IP traffic between us and the USA comes from us to the USA, so the USA should have to pay for that traffic, just like we have to pay for the 70% that we get from the USA, it's just like paying for what you download.
But it's not just about downloading, it's about uploading as well. At least, that's how most traffic based accounting works. And if the ISP is going to charge for the traffic regardless of direction, they might as well equally share peering costs. (And even if traffic is not metered, the same logic applies - the better network infrastructure is a bonus for both sides, so they should share the cost.)
I see a serious problem with the "free music software helps free music" point of view. Musicians are not usually the most computer literate people around, and Jazz is still kind of difficult to install (this is not the first version I tried to check out). OK, so they have a rpm now - guess what it does? It contains the single file/tmp/jazz/jazz-bin-4.0.0.tar.gz and installs from there, then deletes the file. rpm deinstallation is of course not possible that way.
Then it complains about ALSA missing - well, I am using OSS, but that should be supported too. No problem - just a quick look in the documentation (no man page, btw, just some html) to find out that there is a.cfg file with options that can neither be altered from the program nor from the command line. So I configure the program for OSS there. Then it looks for/dev/sequencer2 or/dev/music, neither of which are standard linux devices according to/dev/MAKEDEV. And when I simply link/dev/music to/dev/sequencer, it asks me if I want to use my AWE64 as Midi output (so it kinda works), but when I try to play the demo song jazz.mid, it keeps spitting out errors ("sndctl_tmr_tempo: Invalid argument ioctl time_base: Invalid argument ioctl speed: Invalid argument unknown sequencer status 08" and so on). I stopped here. I doubt the average musician would even have gotten so far without help.
So now I am asking for some - is anybody able to enlighten me what I might be doing wrong?
Just to shed a light on the situation here: Some years ago, it was still possible to get plain copper starting at a rather cheap 60 DM/month (1 DM ~ $0.50). Of course, this was voice grade, but you could still run modems on it. I had such a line in 93, but the local user group whose router I connected to suddenly wanted root permissions on my machines "to be able to control misuse of bandwidth" (or so they phrased it - I wonder if they knew what a router could do, they could have simply dropped packets if they considered the traffic misuse). Of course, I only got told that after shelling out like ~2.500 DM for installation and equipment and six months of 120 DM/month. The line didn't even work the first three months because Linux didn't support PPP at the time and they claimed to have forgotten the password for the access router, so they couldn't switch to SLIP for my line - of course, it would just have taken somebody to actually drive there and sit down at the console.
After this experience I kept checking out alternative solutions, after all, modems didn't really cut it even back than. But by pure coincidence, when the restrictions on equipment connected to these copper lines were dropped (they had to be officially approved for use on the german telecom network first), suddenly bandwidth limiters popped up. Suddenly the telco remembered that they were only obliged to sell 3,1 kHz voice grade service over that copper lines, so they put in filters. You could still get lines without filters if you claimed you wanted to connect two old telex boxes, but you had to show them, and of course you still weren't allowed to run DSL on that line. If there were problems, you were not only alone with them, but the telco could actually sue you if your DSL-signals interfered with other services.
And suddenly the Telekom decides that you _can_ do ADSL, but only in selected areas and if you rent their equipment. Private accounts only have DynIP, run at 768/128, costing 100 DM/Month (including ISDN service) plus 0.03 DM/Minute. Commercial accounts start at ~300 DM/Month (for 768/128, available up to 6144/512) and are basically a leased line configuration with static IP and metered by traffic (~100 DM/GB, depending on total traffic usage).
Still, for many users this is the best offer around. I am using it right now. RTT is around 30ms, which is not really better than ISDN, but comparable, and the throughput is usually ok.
So, before you start bitching about your phone companies, have a look over here and begin feeling better...:)
Yes, this is not _yet_ about indoctrination. Neither was the HJ when it started. You were absolutely free to choose not to join. Of course, this changed with increasing peer pressure.
People should be taught to tolerate other lifestyles, maybe how to discuss them if they don't like them, but not to "report" them as abnormal.
This is just another example of a seemingly good cause being used to lobby for inhuman programs. Giving out incentives to students for spying on their fellow students and reporting peculiarities is inhuman in my opinion.
"It's a carbon copy of the Hitler Youth program used so successfully in World War II Germany to root out dissidents and oddballs."
Actually, this sounds even worse to me. The Hitler Youth was "just" a youth organisation, at least at the beginning. And even later on, the motivation was mostly political and even paramilitary "education" of the members, not using them as a extension of the Gestapo (the Nazi internal intelligence service). The Hitler Youth has to be seen in this context. They were the pre-school of the fascist government, preparing young people to be "good citizens" (in the perverted sense the Nazi government thought of this). Spying on others was not explicitly asked for, at least not as far as I know. (And Nazi history takes up quite a big part in german history education).
It was a bit different with the "Freie Deutsche Jugend", the national youth organisation of the former GDR. Members were explicitly asked to inform their leaders of any planned attempt of "Republikflucht" (unauthorized leave of country, usually to the FRG) they got to know of, and some even turned in their parents.
But what you are talking about _is_ asking for spying on peers, and what's more, it is happening in a democratic nation. Appropriate action should be taken (and I do consider your article as such) before this starts to take off.
Sorry, I didn't manage to get at the original link in time myself. However, this has already been covered last week in this article at ZDF.MSNBC (interestingly!). It's in german, but I'm sure you all know how to use the fish.
"I like having 2 comfortably wide browser windows side by side without overlapping."
Yes, so do I. But the need for that would be far less if web designers would design for less-than-fullscreen browsers instead of simply putting in a note about "best viewed at 1024x768". I do have a large screen (my favorite resolution being a custom 1440x1080 I designed for XFree because 1280 just didn't cut it and my monitor only does 75 Hz at 1600), but I refuse to open my browser in absurdly large widths just because some web designer couldn't think of somebody wanting to do something else besides browsing the site.
An especially ugly example is the web interface to german teletext. Try viewing this at less than 800 pixels width. The page navigation instantly becomes unusable (to use it, you have to scroll the window to the right, but after the next page appears, the slider is all left again), yet there is just a feeble bit of actual information on the page which would have fit in a 40x25 text window if it weren't for the graphics.
(In case anybody is interested in the modeline for 1440x1080 @ 95 kHz/85 Hz, tested and working on a 19" Belinea 106090:
I'd love to give 2.3 a try (and have tried to do so several times), but unfortunately I need to use the newest tulip-driver (0.91g) for my 21143-ethernet-cards, which are not supported by the older driver which still is in 2.3. and the newer one won't compile with 2.3.
Thus, I have to choose between 2.3 without net or 2.2 with net. Guess what the choice is...
This is not a lottery at all. Everybody having checked false keys before increased the chance of the right key being assigned to you, so they _did_ help with your work.
And distributed.net had the first linux client when dcypher.net was still promising one. I am not going to reinstall clients after just having done that on several machines. I also don't really trust a new, closed source, binary only client. While distributed.net isn't exactly open source, either, at least they play as fair as possible and give you nearly the full source with all of the key routines.
Regarding the money: distributed.net only claims 20%, but insists on donating 60% to a charity. Anybody can suggest one, but the one to get the 60% is decided by vote (everyone gets one vote per block done). Which is only fair. Why should one person get all the money tens of thousands of people have worked for? This isn't for the money, after all. And the odds of finding the key are slim.
So with distributed.net, you are working for a donation to a charity, which is certain. With dcypher.net, you are trying to get all the money, while most probably somebody else will get it, leaving you _and_ a worthy cause without money.
(The above leaves 20% for the participant, which gets split with his team if he joined one.)
> It's unbelievable how many people are confused over this.
Yes, it is. There are still people who recommend SCSI without further investigation.
> For example, let's say your system is trying to read data and do a write at the same time.
No decent OS would do that. It would concentrate on reads and save the writes for later, unless the write cache is full.
> With IDE your OS has to issue one command to the controller which passes it to the device and then waits...
With IDE maybe. With ATA not. ATA does have everything that SCSI has, and more. Read the specs at www.t13.org.
> With SCSI, the OS tells the controller all the operations it wants to do and the controller looks at it and decides if there is an optimal way of doing the commands.
Of course, only if you have a host adapter / driver which support command queueing, and an application that _does_ do multiple accesses at the same time. Most don't. And a decent OS reorders the commands anyway before they are sent to disk, partly eliminating the need for reordering by the drive.
TyFoN wrote: "When i use my ide disk i can't even move the mouse."
You fail to mention which chipset and transfer mode you are using. And there _are_ SCSI hosts that do a lot worse than recent ATA interfaces (the cheap ISA-Adaptecs that come bundled with scanners and ZIPs for example).
I once was a SCSI advocate, too. Then came the Intel PIIX3 and Mword DMA mode 2, nowadays I am using a PIIX4 and UDMA33. I have _never_ had my system go slow on me with DMA ATA drives, much less the mouse pointer stop moving.
There is just one special case: Swapping to ATA drives can put more of a load on the system under certain circumstances (because I haven't seen ATA drivers use command queueing yet - it's already specified in the ATA spec, though), but you don't really want to be swapping in the first place. If your system does that constantly, you should have gone for more RAM instead of that pricey SCSI drive.
There is really not so much that differentiates ATA from SCSI anymore. ATA (formerly known as IDE) drives have been remapping bad blocks transparently for years, they have been doing DMA for nearly as long, and some drives even came in ATA and SCSI versions (IBM DCAA/DCAS for one), where only the interface board was different and absolutely everything else was equal.
There is even a usable external ATA RAID subsystem out there, manufactured by Arena. They use the same i960 that is used on high end SCSI RAID controllers and deliver decent performance with cheap drives. (Remember: The I in RAID once meant inexpensive)
Of course, in a server, you want reliable drives. But that has next to nothing to do with the interface. UDMA is very reliable as far as the interface data transfer is concerned, I would rate it even higher than SCSI in this regard (proper CRC vs. ordinary parity). The quality of the disk mechanism is another thing, but with IDE drives being so cheap, you could afford to upgrade the things so quickly that they never get a chance to fail at work. Or you could just buy two big ATA drives for less than one SCSI drive and do RAID1.
For the records: Recent ATA drives really scream. Look at these bonnie results from my workstation (dual P2, 128M, Red Hat 6.1, 2.2.13, Test run on 2 GB / Partition 50% full):
The drive is a 20 GB Seagate ST320430A which sells for less than 400 DM around here. Remember: These are not artificial results on an empty filesystem. This is my real root partition which is used daily.
distributed.net has no problems with a nearly open sourced client. The public source can't fetch or flush blocks, but it can do the computations, so anybody who wants to can optimize the routines that do the actual work.
I just don't see why a similar approach wouldn't work with S@H. They could still do coordinated releases, but could also include optimizations not done by them if independent verifications show the code to be working alright.
And regarding the Pentium FPU bug - I doubt that the actual client checks for it. It would severely decrease performance on processors without the bug. _If_ the client checks for it, it should do so in its self test and refuse running if the self test fails.
Holger
(still running d.net clients exclusively because SETI is so obviously desinterested in people who donate their computing times)
There ARE already different implementations of the algorithm. seti@home does _not_ rely on a single type of machine under a single type of OS. So the variable is already there, and it doesn't get anything less variable by not optimizing for specific processors in a family. SETI should accept the help offered and concentrate on reliability testing of the implementations.
After all it is nothing but math. You can do it any style you want as long as it is equivalent.
With a traditional modem, there are three main sources of latency.
First, usually PPP is used for dialup IP connections. Unlike sync ppp over ISDN (or leased lines), it has to run asynchronous because it has no way of sending packets with the traditional command set. It can only send bytes. SyncPPP, on the other hand, sends whole packets delivered directly to the HDLC link layer. I know of no Hayes command extension that allows direct access to individual V.42 packets.
Second, with external modems, the data needs to get converted to serial and back to parallel. This adds less latency with higher port speeds, but even at 115200 bps, a byte still takes ~0.1ms to even get to the modem. This is less of a problem with newer internal modems, which just look like a 16550 to the software, but have no serial data path because what's looking like a 16550 is a clever interface for the modem chip itself.
Third, the modem needs to do error correction, which involves receiving a whole block (of 256 bytes usually) before it can be sent on to the computer. Anything without error correction could sometimes deliver low latency, but the first need for retransmission would ruin average latency, because the need for retransmission is not detected by the modem, but by the PPP layer above. (Imagine a 1500 byte packet that needs to be retransmitted because of a transmission error. Could take a whole second with older modems, at least 250ms with decent ones)
The real key to low latency modems would be implementing a direct packet access scheme for the PPP driver, or implementing PPP on the modem itself (ideally with some kind of link level compression). Then, with the other side properly tuned as well, a packet could be transferred with no more latency than is needed for the transmission itself, because PPP would eliminate the need for V.42 and CCP would eliminate the need for V.42bis. And - implemented either in hardware or in software with a broad data path to the actual line interface - these would be pretty fast.
There is some work on Linux-Softmodems underway. These should excel in latency, when finished and properly supported by pppd, because they implement most of the ideas above. They still need help, but there is source code already available here.
I was expecting this, but I'd thought it to come earlier. When 3com bought USR, they wanted the modem and ISDN technology, not the handheld, which doesn't fit in their product range at all. It made a bit of sense for USR (after all, that's a device possibly in need of a modem), but not for 3com. This should be a good move for everybody involved. Maybe even the Newton would still be alive if Apple went a route like this...
rather than doing a hard reset every 2 or 3 weeks, the "karma zone" should just take a running time period of 2 or 3 weeks.
Which would still encourage posting regularly, even if one doesn't really have much informative to say. I'm not really sure if that would be "a good thing". As it is, slashdot already is too much to read. I often find myself wanting to read slashdot at a default level of +3 instead of my current +2, just because there are so much less than interesting postings that got moderated up nevertheless, or were 2 by default. I'll probably change it sometime soon.
So, why should karma expire at all? If the concern is about karma going to high, one could always divide it by the number of postings. Or have it expire gradually. (new = (old * 10 + this week) / 11 )
After all, it's highly unlikely that somebody who acquired a high karma loses his ability to post good comments just because he was on vacation for some weeks.
The main page could be served "pseudodynamic" (read: changed only when a new story appears, comment counts left off). The same could be done for all users who are logged in but still use default settings (ok, the personalized line at the top would have to be missing), or for all articles (ok, maybe not updating for every single comment, more like every 10 minutes or so). This should take some serious load off the servers. And btw, Rob: Ever thought of offering slashdot via NNTP? It's basically a news site, and that's just what news were meant for. Sometimes I wonder why everything has to be reinvented via the web. I'd love slashdot.[topic].announce for the articles and slashdot.[topic].d for comments, maybe even slashdot.[topic].moderated for articles that get moderated to, say, two or higher. freshmeat is available via NNTP already, though I agree that it's a lot easier for them, without as many comments.
I was always wondering why slashdot is so heavily depending on dynamically generated pages. Even if just the main page had proper caching information, you could already hand off all the anonymous users (people not logged in) to the worldwide caching hierarchy out there.
See what the cacheability engine on ircache.net has to say about slashdot.org. At least the gifs are cacheable, but why is that "Expires"-Tag set? Do you expect the gifs to change every week?
Have you checked out grip? It's a Gtk-based frontend for cdparanoia and lame (some other rippers / encoders supported, too) and it is absolutely awesome. Automatic CDDB-query (even gives you the option to submit a successful cddb-lookup to freecddb, if it didn't have it), support for multiprocessor systems, you name it. http://www.ling.ed.ac.uk/~oliphant/grip/
Slashdot Mirror
Your idea isn't new. A german inventor had something like that worked out about five years ago, they are finally through the patenting process and are starting to produce actual hardware. Check out www.dirc.net. Unfortunately the original idea "user buys equipment once, no further costs" has been dropped in the process. Now the business model is more along the lines of "provider buys lots of them and rents them out to consumers". But still pretty cool tech.
Actually, shifting a color value by some bits to the right _is_ the correct way to convert to lower bit resolution (each color component independently, of course). If you were to take the remaining bits into account (maybe rounding up by 1 if the next bit is 1), you'd get a problem. what would you round 0xffffff to? The only problem is that there are different mappings for pictures and bgcolor (probably one of them gets it right, one wrong). That's a plain old bug that needs to be fixed, nothing to be worked around. You can use the lower bits only when dithering, not when choosing the best approximation for a single color.
30% of IP traffic between us and the USA comes from us to the USA, so the USA should have to pay for that traffic, just like we have to pay for the 70% that we get from the USA, it's just like paying for what you download.
But it's not just about downloading, it's about uploading as well. At least, that's how most traffic based accounting works. And if the ISP is going to charge for the traffic regardless of direction, they might as well equally share peering costs. (And even if traffic is not metered, the same logic applies - the better network infrastructure is a bonus for both sides, so they should share the cost.)
It was released for the Amiga as well. I had no MIDI equipment whatsoever back then, but it could use the internal audio, too.
Later on, the Amiga also had "Bars&Pipes", which was pretty cool for its time, too.
I see a serious problem with the "free music software helps free music" point of view. Musicians are not usually the most computer literate people around, and Jazz is still kind of difficult to install (this is not the first version I tried to check out). OK, so they have a rpm now - guess what it does? It contains the single file /tmp/jazz/jazz-bin-4.0.0.tar.gz and installs from there, then deletes the file. rpm deinstallation is of course not possible that way.
.cfg file with options that can neither be altered from the program nor from the command line. So I configure the program for OSS there. Then it looks for /dev/sequencer2 or /dev/music, neither of which are standard linux devices according to /dev/MAKEDEV. And when I simply link /dev/music to /dev/sequencer, it asks me if I want to use my AWE64 as Midi output (so it kinda works), but when I try to play the demo song jazz.mid, it keeps spitting out errors ("sndctl_tmr_tempo: Invalid argument ioctl time_base: Invalid argument ioctl speed: Invalid argument unknown sequencer status 08" and so on). I stopped here. I doubt the average musician would even have gotten so far without help.
Then it complains about ALSA missing - well, I am using OSS, but that should be supported too. No problem - just a quick look in the documentation (no man page, btw, just some html) to find out that there is a
So now I am asking for some - is anybody able to enlighten me what I might be doing wrong?
Just to shed a light on the situation here: Some years ago, it was still possible to get plain copper starting at a rather cheap 60 DM/month (1 DM ~ $0.50). Of course, this was voice grade, but you could still run modems on it. I had such a line in 93, but the local user group whose router I connected to suddenly wanted root permissions on my machines "to be able to control misuse of bandwidth" (or so they phrased it - I wonder if they knew what a router could do, they could have simply dropped packets if they considered the traffic misuse). Of course, I only got told that after shelling out like ~2.500 DM for installation and equipment and six months of 120 DM/month. The line didn't even work the first three months because Linux didn't support PPP at the time and they claimed to have forgotten the password for the access router, so they couldn't switch to SLIP for my line - of course, it would just have taken somebody to actually drive there and sit down at the console.
:)
After this experience I kept checking out alternative solutions, after all, modems didn't really cut it even back than. But by pure coincidence, when the restrictions on equipment connected to these copper lines were dropped (they had to be officially approved for use on the german telecom network first), suddenly bandwidth limiters popped up. Suddenly the telco remembered that they were only obliged to sell 3,1 kHz voice grade service over that copper lines, so they put in filters. You could still get lines without filters if you claimed you wanted to connect two old telex boxes, but you had to show them, and of course you still weren't allowed to run DSL on that line. If there were problems, you were not only alone with them, but the telco could actually sue you if your DSL-signals interfered with other services.
And suddenly the Telekom decides that you _can_ do ADSL, but only in selected areas and if you rent their equipment. Private accounts only have DynIP, run at 768/128, costing 100 DM/Month (including ISDN service) plus 0.03 DM/Minute. Commercial accounts start at ~300 DM/Month (for 768/128, available up to 6144/512) and are basically a leased line configuration with static IP and metered by traffic (~100 DM/GB, depending on total traffic usage).
Still, for many users this is the best offer around. I am using it right now. RTT is around 30ms, which is not really better than ISDN, but comparable, and the throughput is usually ok.
So, before you start bitching about your phone companies, have a look over here and begin feeling better...
Quoted from their "conclusion":
"We had not troubles operating the same setup at 1066MHz, although very unstable [...]"
If "very unstable" doesn't count as trouble, I don't know what does.
Yes, this is not _yet_ about indoctrination. Neither was the HJ when it started. You were absolutely free to choose not to join. Of course, this changed with increasing peer pressure.
People should be taught to tolerate other lifestyles, maybe how to discuss them if they don't like them, but not to "report" them as abnormal.
This is just another example of a seemingly good cause being used to lobby for inhuman programs. Giving out incentives to students for spying on their fellow students and reporting peculiarities is inhuman in my opinion.
"It's a carbon copy of the Hitler Youth program used so successfully in World War II Germany to root out dissidents and oddballs."
Actually, this sounds even worse to me. The Hitler Youth was "just" a youth organisation, at least at the beginning. And even later on, the motivation was mostly political and even paramilitary "education" of the members, not using them as a extension of the Gestapo (the Nazi internal intelligence service). The Hitler Youth has to be seen in this context. They were the pre-school of the fascist government, preparing young people to be "good citizens" (in the perverted sense the Nazi government thought of this). Spying on others was not explicitly asked for, at least not as far as I know. (And Nazi history takes up quite a big part in german history education).
It was a bit different with the "Freie Deutsche Jugend", the national youth organisation of the former GDR. Members were explicitly asked to inform their leaders of any planned attempt of "Republikflucht" (unauthorized leave of country, usually to the FRG) they got to know of, and some even turned in their parents.
But what you are talking about _is_ asking for spying on peers, and what's more, it is happening in a democratic nation. Appropriate action should be taken (and I do consider your article as such) before this starts to take off.
Sorry, I didn't manage to get at the original link in time myself. However, this has already been covered last week in this article at ZDF.MSNBC (interestingly!). It's in german, but I'm sure you all know how to use the fish.
"I like having 2 comfortably wide browser windows side by side without overlapping."
:)
Yes, so do I. But the need for that would be far less if web designers would design for less-than-fullscreen browsers instead of simply putting in a note about "best viewed at 1024x768". I do have a large screen (my favorite resolution being a custom 1440x1080 I designed for XFree because 1280 just didn't cut it and my monitor only does 75 Hz at 1600), but I refuse to open my browser in absurdly large widths just because some web designer couldn't think of somebody wanting to do something else besides browsing the site.
An especially ugly example is the web interface to german teletext. Try viewing this at less than 800 pixels width. The page navigation instantly becomes unusable (to use it, you have to scroll the window to the right, but after the next page appears, the slider is all left again), yet there is just a feeble bit of actual information on the page which would have fit in a 40x25 text window if it weren't for the graphics.
(In case anybody is interested in the modeline for 1440x1080 @ 95 kHz/85 Hz, tested and working on a 19" Belinea 106090:
# 1440x1080 @ 85 Hz, 95 kHz hsync
Modeline "1440x1080" 184.6 1440 1504 1664 1944 1080 1083 1086 1117
As always: No warranties that it doesn't kill your monitor, but at least it works for mine
I'd love to give 2.3 a try (and have tried to do so several times), but unfortunately I need to use the newest tulip-driver (0.91g) for my 21143-ethernet-cards, which are not supported by the older driver which still is in 2.3. and the newer one won't compile with 2.3.
Thus, I have to choose between 2.3 without net or 2.2 with net. Guess what the choice is...
Holger
This is not a lottery at all. Everybody having checked false keys before increased the chance of the right key being assigned to you, so they _did_ help with your work.
And distributed.net had the first linux client when dcypher.net was still promising one. I am not going to reinstall clients after just having done that on several machines. I also don't really trust a new, closed source, binary only client.
While distributed.net isn't exactly open source, either, at least they play as fair as possible and give you nearly the full source with all of the key routines.
Regarding the money: distributed.net only claims 20%, but insists on donating 60% to a charity. Anybody can suggest one, but the one to get the 60% is decided by vote (everyone gets one vote per block done). Which is only fair. Why should one person get all the money tens of thousands of people have worked for? This isn't for the money, after all. And the odds of finding the key are slim.
So with distributed.net, you are working for a donation to a charity, which is certain. With dcypher.net, you are trying to get all the money, while most probably somebody else will get it, leaving you _and_ a worthy cause without money.
(The above leaves 20% for the participant, which gets split with his team if he joined one.)
Holger
> It's unbelievable how many people are confused over this.
Yes, it is. There are still people who recommend SCSI without further investigation.
> For example, let's say your system is trying to read data and do a write at the same time.
No decent OS would do that. It would concentrate on reads and save the writes for later, unless the write cache is full.
> With IDE your OS has to issue one command to the controller which passes it to the device and then waits...
With IDE maybe. With ATA not. ATA does have everything that SCSI has, and more. Read the specs at www.t13.org.
> With SCSI, the OS tells the controller all the operations it wants to do and the controller looks at it and decides if there is an optimal way of doing the commands.
Of course, only if you have a host adapter / driver which support command queueing, and an application that _does_ do multiple accesses at the same time. Most don't. And a decent OS reorders the commands anyway before they are sent to disk, partly eliminating the need for reordering by the drive.
TyFoN wrote: "When i use my ide disk i can't even move the mouse."
You fail to mention which chipset and transfer
mode you are using. And there _are_ SCSI hosts that do a lot worse than recent ATA interfaces (the cheap ISA-Adaptecs that come bundled with scanners and ZIPs for example).
I once was a SCSI advocate, too. Then came the Intel PIIX3 and Mword DMA mode 2, nowadays I am using a PIIX4 and UDMA33. I have _never_ had my system go slow on me with DMA ATA drives, much less the mouse pointer stop moving.
There is just one special case: Swapping to ATA drives can put more of a load on the system under certain circumstances (because I haven't seen ATA drivers use command queueing yet - it's already specified in the ATA spec, though), but you don't really want to be swapping in the first place. If your system does that constantly, you should have gone for more RAM instead of that pricey SCSI drive.
There is really not so much that differentiates ATA from SCSI anymore. ATA (formerly known as IDE) drives have been remapping bad blocks transparently for years, they have been doing DMA for nearly as long, and some drives even came in ATA and SCSI versions (IBM DCAA/DCAS for one), where only the interface board was different and absolutely everything else was equal.
/sec %CPU
There is even a usable external ATA RAID subsystem out there, manufactured by Arena. They use the same i960 that is used on high end SCSI RAID controllers and deliver decent performance with cheap drives. (Remember: The I in RAID once meant inexpensive)
Of course, in a server, you want reliable drives. But that has next to nothing to do with the interface. UDMA is very reliable as far as the interface data transfer is concerned, I would rate it even higher than SCSI in this regard (proper CRC vs. ordinary parity). The quality of the disk mechanism is another thing, but with IDE drives being so cheap, you could afford to upgrade the things so quickly that they never get a chance to fail at work. Or you could just buy two big ATA drives for less than one SCSI drive and do RAID1.
For the records: Recent ATA drives really scream. Look at these bonnie results from my workstation (dual P2, 128M, Red Hat 6.1, 2.2.13, Test run on 2 GB / Partition 50% full):
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU
512 18196 97.7 23648 22.5 10807 19.1 19702 84.2 23128 6.9 129.9 2.0
The drive is a 20 GB Seagate ST320430A which sells for less than 400 DM around here. Remember: These are not artificial results on an empty filesystem. This is my real root partition which is used daily.
distributed.net has no problems with a nearly
open sourced client. The public source can't fetch or flush blocks, but it can do the computations, so anybody who wants to can optimize the routines that do the actual work.
I just don't see why a similar approach wouldn't work with S@H. They could still do coordinated releases, but could also include optimizations not done by them if independent verifications show the code to be working alright.
And regarding the Pentium FPU bug - I doubt that the actual client checks for it. It would severely decrease performance on processors without the bug. _If_ the client checks for it, it should do so in its self test and refuse running if the self test fails.
Holger
(still running d.net clients exclusively because SETI is so obviously desinterested in people who donate their computing times)
There ARE already different implementations of the algorithm. seti@home does _not_ rely on a single type of machine under a single type of OS. So the variable is already there, and it doesn't get anything less variable by not optimizing for specific processors in a family. SETI should accept the help offered and concentrate on reliability testing of the implementations.
After all it is nothing but math. You can do it any style you want as long as it is equivalent.
Holger
With a traditional modem, there are three main sources of latency.
First, usually PPP is used for dialup IP connections. Unlike sync ppp over ISDN (or leased lines), it has to run asynchronous because it has no way of sending packets with the traditional command set. It can only send bytes. SyncPPP, on the other hand, sends whole packets delivered directly to the HDLC link layer. I know of no Hayes command extension that allows direct access to individual V.42 packets.
Second, with external modems, the data needs to get converted to serial and back to parallel. This adds less latency with higher port speeds, but even at 115200 bps, a byte still takes ~0.1ms to even get to the modem. This is less of a problem with newer internal modems, which just look like a 16550 to the software, but have no serial data path because what's looking like a 16550 is a clever interface for the modem chip itself.
Third, the modem needs to do error correction, which involves receiving a whole block (of 256 bytes usually) before it can be sent on to the computer. Anything without error correction could sometimes deliver low latency, but the first need for retransmission would ruin average latency, because the need for retransmission is not detected by the modem, but by the PPP layer above. (Imagine a 1500 byte packet that needs to be retransmitted because of a transmission error. Could take a whole second with older modems, at least 250ms with decent ones)
The real key to low latency modems would be implementing a direct packet access scheme for the PPP driver, or implementing PPP on the modem itself (ideally with some kind of link level compression). Then, with the other side properly tuned as well, a packet could be transferred with no more latency than is needed for the transmission itself, because PPP would eliminate the need for V.42 and CCP would eliminate the need for V.42bis. And - implemented either in hardware or in software with a broad data path to the actual line interface - these would be pretty fast.
There is some work on Linux-Softmodems underway. These should excel in latency, when finished and properly supported by pppd, because they implement most of the ideas above. They still need help, but there is source code already available here.
Holger
I was expecting this, but I'd thought it to come earlier. When 3com bought USR, they wanted the modem and ISDN technology, not the handheld, which doesn't fit in their product range at all. It made a bit of sense for USR (after all, that's a device possibly in need of a modem), but not for 3com.
This should be a good move for everybody involved.
Maybe even the Newton would still be alive if Apple went a route like this...
rather than doing a hard reset every 2 or 3 weeks, the "karma zone" should just take a running time period of 2 or 3 weeks.
Which would still encourage posting regularly, even if one doesn't really have much informative to say. I'm not really sure if that would be "a good thing". As it is, slashdot already is too much to read. I often find myself wanting to read slashdot at a default level of +3 instead of my current +2, just because there are so much less than interesting postings that got moderated up nevertheless, or were 2 by default. I'll probably change it sometime soon.
So, why should karma expire at all? If the concern is about karma going to high, one could always divide it by the number of postings. Or have it expire gradually. (new = (old * 10 + this week) / 11 )
After all, it's highly unlikely that somebody who acquired a high karma loses his ability to post good comments just because he was on vacation for some weeks.
The main page could be served "pseudodynamic" (read: changed only when a new story appears, comment counts left off). The same could be done for all users who are logged in but still use default settings (ok, the personalized line at the top would have to be missing), or for all articles (ok, maybe not updating for every single comment, more like every 10 minutes or so). This should take some serious load off the servers.
And btw, Rob: Ever thought of offering slashdot via NNTP? It's basically a news site, and that's just what news were meant for. Sometimes I wonder why everything has to be reinvented via the web.
I'd love slashdot.[topic].announce for the articles and slashdot.[topic].d for comments, maybe even slashdot.[topic].moderated for articles that get moderated to, say, two or higher.
freshmeat is available via NNTP already, though I agree that it's a lot easier for them, without as many comments.
I was always wondering why slashdot is so heavily depending on dynamically generated pages. Even if just the main page had proper caching information, you could already hand off all the anonymous users (people not logged in) to the worldwide caching hierarchy out there.
See what the cacheability engine on ircache.net has to say about slashdot.org. At least the gifs are cacheable, but why is that "Expires"-Tag set? Do you expect the gifs to change every week?
Have you checked out grip? It's a Gtk-based frontend for cdparanoia and lame (some other rippers / encoders supported, too) and it is absolutely awesome. Automatic CDDB-query (even gives you the option to submit a successful cddb-lookup to freecddb, if it didn't have it), support for multiprocessor systems, you name it. http://www.ling.ed.ac.uk/~oliphant/grip/