1) Speed is already one of the most emphasized design goals of the Linux kernel. If you have never read the Linux kernel source, then you're probably not aware of the numerous gcc-specific tricks and tangled code that is used to speed optimizations. Trust me. The kernel is as fast as it's going to get.
>>>>>>>>>>>>>>>>>
I know the kernel does a good job with speed. However, it is NEVER fast enough. There is always some more tuning that can be done, somewhere.
2) It is standardized between every incremental revision, as much as any driver model can be standardized. The major changes only come between minor and major revisions, such
as 2.2 -> 2.3/2.4.
>>>>>>>>>>>>
It is not "officially" standardize. Stuff can, and does break. The NVIDIA kernel drivers broke three times over the period of a few kernels. That's not good. If there was an official decree that "all 2.4.X" kernels will have a standard driver interface, then you wouldn't have to worry about breaking drivers until the next rev rolled around in 2 years.
3) Whatever.
>>>>>>
Good god, subtlety is lost on you people. Didn't the smiley face give away the fact that I was kidding!
4) Nonsense. The kernel uses the user-level helper tasks for efficiency's sake. If you haven't studied the kernel module loading system, then you shouldn't really be talking about it. Standardization of config files is also impossible in many cases do to the differences between said devices.
>>>>>>>>>>>>>>>>>>>>>
I really don't see how config files can't be standardized. The XML stuff floating around on this discussion sounds like a great idea. Also, using user-level processes to load drivers is a stupid idea. BeOS has by far the best driver loading sheme of any OS out there (OSs that don't have Quake ports are excluded) The system takes care of system stuff (loading drivers) and you only have to get involved when something goes wrong (rare.) Installing new drivers amounts to copying an add-on (a dynamically loaded.so) into the proper directory. It doesn't get any damn easier.
5) Might be nice.
6) Okay, now this just shows total ignorance of how Linux and software/system interaction in general works. The kernel's treatment of threads is that they are equal to processes that share the same memory mapping structures. The Linux scheduler handles thread-switching quite admirably, and you will be hard-pressed to find any desktop OS scheduler that performs as well as Linux's. The major misconception here is in assuming that "pervasive multi-threading" is all the kernel's responsibility. That is all the responsibility of the
user-level library and application code. The kernel schedules and relegates threads. It's the user-level code that responsible for taking advantage of the threading facilities
available.
>>>>>>>>>>>>>>>>>
It's not the kernel responsibility, but unless the kernel itself is super thread friendly (multi-threading the kernel itself helps in this respect) it is harder to make multi-threaded apps. Also, the kernel can "force" multi threading on apps in which it is useful.
You seem to be bound up in the desktop world of "GUI == part of OS." In Linux, the GUI is a user-level application, as well it should be in the case of what they have available.
>>>>>>>>>
How do you derive that? The OS that I use 90% of the time has NETWORKING in userspace.
God forbid anyone attempt to weld the Unseelie monstrosity that is X11 into the kernel. That would introduce bloat and instability into the entire system.
>>>>>>>>>>
yea, that's why it is abad idea!
This is why there
aren't kernel-level SAMBA implementations, BTW. The responsiveness of the desktop interface is not the Linux kernel's fault. The fact is that QNX and BeOS both have very well written GUI layers.
>>>>>>>>>>>>
As I said, the kernel can force correct behavior. Also, I'm not only talking GUI here, BeOS has audio latencies that approach that of RTLinux, and the context-switch/event response times for QNX blow everything else out of the water. Trust me, there is room for the kernel to improve.
However, to claim that they are in general more responsive is a little bit of marketing/evangelism propoganda. The responsiveness of the Linux kernel is
very, very nice on a process/thread level.
>>>>>>>>
It is very, very nice. Just not as nice as some of the other OSs out there. Given the volume of talent devoted to Linux, there is no reason Linux's response shouldn't exceed that of those other OSs.
2) If the standard is designed correctly only the occasional device would need to break it. I mean there isn't much difference at the driver level, an ethernet driver is an ethernet driver, and there is no reason to change it between minor revision. It doesn't happen much anyway, but I think making it an official policy would keep drivers from breaking. Take, for example, the fact that the NVIDIA kernel interface broke three or four times. That is really too much.
3) I was kidding. I know, subtlety is hard.
4) Automatic loads != no choice. It simply means that you don't have to fuss with it unless you want to. In BeOS, if you want to load a different driver, then you just mv the old driver out of the driver directory heirarchy and substitute the new one. If you need to change the default parameters, you can edit the driver config file (each driver that has configurable parameters has a paired config file that uses a fairly standard parsing method across different drivers) The point is, that you don't have to hand control unless you want to.
5) Then fix ALSA. There should be only ONE low-level Linux sound API.
6) Agreed. Its a wonder that Linux doesn't take better advantage of its OSS nature by specializing kernels. It would even be possible to keep the APIs the same, so different, compatible, kernels could be tuned for different tasks. It would take more work, but isn't the huge number of programmers one of the advantages of OSS?
The registry isn't the thing that's bloated, its the apps that use the registry irresponsbily. The apps that leave dead wood lying around and write to wrong keys. The problem persists wheter or not that feature is in Linux.
The sysadmins need to get their heads out of their asses and learn something new? And if they aren't, they should probably be using Windows. How many times have you heard the argument, "Linux is different, users should learn how to use it!" The same thing should apply for sysadmins.
1) Speed it up. The kernel already does a great job with speed, but don't trade speed for gee-wiz features that 1% of the population uses. That's what third party patches are for. Keep the standard kernel as general/lightweight as possible.
2) Standardize the driver interface. Yea, it takes actual thinking to come up with a good interface and stick with it, but it would only have to hold between major version changes (a nice trade-off between a single driver interface forever) and you really shouldn't be changing the driver interface between 2.4.1 and 2.4.18 anyway.
3) Put hooks in to only allow KDE to run. Although methinks that's not going to happen anytime soon;)
4) Standardize configuration. modules.conf, moduels.rc and all of the config programs (iptables, ipchains, etc) are too much. Get rid of modeprobe, kerneld, etc, and have the kernel automatically load modules itself, maybe with some help from config files. BeOS can automatically load the correct drivers for its hardware and there is no reason Linux shouldn't be able to do the same. Finally, standardize the configuaration of kernel modules. All kernel modueles, from iptables to joystick drivers should be configured the same way, either through a strict hierarchy of config files, or through a standard program.
5) Replace OSS with ALSA and tie it to the standard configuaration mode discussed above. I know they're working on that, any idea when it will be finished?
6) Make it more thread rather than process oriented. Make it totally reentrant, and make it highly multi-threaded. As anyone whose used BeOS will tell you, "pervasive multi-threading" is far more than just a buzz-word. QNX, AtheOS, and BeOS are all highly multi-threaded and are three of the most responsive desktop OSs available. That's no coincidence.
Standardization != lack of choices. If you hadn't noticed, cars have become incredibly standardized these days, yet nobody complains that there aren't enough choices. Or take graphics cards. Everybody has standardized on D3D/OpenGL interfaces, and yet there are still tons of choices. Or soundcards, everyone uses DSound3D w/ EAX, yet I still can't decide whether to get one of the new fangled cards or stick with a good old SBLive!. I really doubt anybody would care whether a distro uses.debs or.RPMS. Pick the best one and stick with. Standardize the directory layout. Standardize the config file layout. Set a minimum level of software (that will means kernels will have to become totally compatible at the driver level between 2.X.Y versions. Meaning drivers from 2.4.0 should work flawlessly without recompilation on 2.4.17) Specify that any new distro adhering to the Linux 2.4 standard needs to have a 2.4 compatible kernel, a glibc 2.0.3 compatible c-library, ncurses 5.0 compatible ncurses library, etc. Nobody really gives a flying f*ck what version their ncurses library is, so why not standardize it? Specify a standard set of libraries so joe's-own-stupid-library.so.56 can be left out of distros. Standardize on Perl or Python (pick one dammit!) for config scripts so other stuff didn't have to be installed. Standardize on bash (or tcsh or zsh or whatever) for shell scripts and stick with it. None of this prevents any user from using whatever they want, it just forces developers (developers don't have nearly as many rights as they think they do) to standardize on one set of programs so users who don't use other things don't need to have them installed. Once you set up a baseline, then the distro makers are free to do whatever they bloody well want. Slackware can continue to balance performance/modernness for stability, Debian can contiue to use the oldest, stablest software possible (as long as it meets the baseline), and Suse can continue to stuff 2.X-pre1-ac1 kernels into its distros. Most of the concessions the distro makers would have to make really wouldn't affect anybody that much. Unless of course you cannot stand the thought of KDE in/usr, in which case you could always use a non-standard distro.
embedded: QNX, Beos
>>>>>>>>>>
You do realize that BeOS is a desktop OS and not an embedded one? BeIA is probably what you're referring to. In the embedded market, there are MANY other OSs besides QNX and BeOS. These two are probably best for stuff like handhelds or web pads, but you go into the automated machinery OSs and these two don't cut it.
workstation: w2k,
>>>>>>>>>
Huh, funny. NT4 kicks Win2K's ass all over the place on the workstation. If it fits right (ie its got the software you want), then BeOS also makes a great workstation OS. Linux also makes a pretty decent workstation OS that's getting better everyday.
small office server: w2k, novell, osX
>>>>>>>>>>
osx-server is totally unproven. Win2K is easy to admin, but Linux, FreeBSD or Novell are probably best here.
web server: *BSD, w2k
>>>>>>>>>>>>>>>
Agreed, but Linux can do this too.
realtime: Inferno, QNX
>>>>>>>>>>>
Who actually uses Inferno? QNX is good but there are a lot of other hard realtime OSs that are better depending on the use. In this catagory, the OS is so use dependant, that you can't classify any one OS as the best.
games: w2k (+aka "whistler")
>>>>>>>>
Bullshit. Win95 all the way. Win98 is slower and more unstable, Millenium is significantly slower, and Win2K's OpenGL support is crappy. If you're games run well in OpenGL, then NT4 kicks everything's ass as a game OS. When more games get ported to BeOS (and if the OpenGL is as good as the previews show it to be) then BeOS will also be competitive as a gaming OS.
Good grief,/. changes the default posting mode every day? (Or is it just a concpiracy. Does/. detect NetPositive and go about screwing hapless BeOS users?)
Linux has so many problems on the desktop it isn't even funny. Sure the basics are there, but it is all so poorly put together that it is quite obvious to anyone why Linux on the mass-market desktop isn't taking off. I think the best thing to do would be to work to polish Linux up. Forget about putting more nifty features in the DEs, creating four different filesystems, a browser that rivels Emacs in overkill factor and get the basics done. For example:
1) Polish up X. 4.0 was a huge leap forward for people in terms of usability, but it still needs work. First, get a GUI to configure it. Relying on a text file to configure something like inetd is one thing; it is so complex that a GUI would be very confusing. However, XFree86Config has so little in it, a GUI should be no problem! All it does is specify a list of modules, specify fontpaths, and set some options for input/output devices. It would be a piece of cake to totally wrap all the features of xf86config (XF86Setup still hasn't been updated yet, AIRC) into a nice GUI program. Second, make it as usable as every other GUI interface in existance. Every single GUI I've ever used, (BeOS, all flavors of Windows since 3.0, QNX Photon, OS/2) have let you choose an exact refresh rate. Why the hell can't X do it? (The sad part is that it probably can, but in the last hour that i've been trying, I can find neither the documentation that says so, nor does anything that comes with the X distro tell me how to do so. Maybe I should read the source?) Hell, even accelerated X lets you set the exact refresh rate! Why can't X change the resolution on the fly? You wouldn't believe how useful BeOS's seperate workspace/seperate res setting is. It helps when you're doing graphics work, when you're doing web work, and even when you're gaming. Set one of the 32 workspaces to a certain resoluation and just switch to that and load your 640x480 game. Lastly, speed it up. Again, 4.0 has made huge strides in this area, but it is still not good enough. The sad part is that the X guys are probably the ones who most "get" what is wrong with Linux on the desktop and are working to fix it.
2) Get a standard DE API. Its great that there are all sorts of UIs out there, that's not a problem. What IS a problem is that there are different APIs for them. All software should be coded for one GUI API, and the window manager should interpret that as necessary. It is totally horrible to anyone with any sense of cleanliness to see the mess that is the miasma of libraries that makes up a common Linux system. You've got TclX, KDE, GNOME, OpenStep, straight-X, Motif, FLTK, etc. That is ugly, ass-ugly. It also makes Linux take up as much RAM as Win2K. That is simply wrong. Not only that, it is confusing. Mandrake installs dozens of different apps that do the same thing, but use different UIs. For example, you can get XCDRoast (ugly UI), gnometoaster (I don't use GNOME) or cdrecord (CLI, hah!) In an ideal world, there would be one GUI API and no matter what desktop you used, it would work. I liked the way it was in the pre enlightenment era when apps weren't tied to DEs. All apps worked on WindowMaker, FVWM, MWM, etc without extra libraries, and with the same (butt-ugly) straight-X interface. Sure you can run a GNOME app in KDE, but it still quacks like a GNOME app, waddles like a GNOME app, and tastes like a GNOME app. (I dislike duck, chicken is best.)
3) Make the advanced features of Linux more accessible. All the cool features that make Linux worthwhile to switch too are often hidden to the average user. If you run KDE, the only thing you gain over running Windows is more stability. All the stuff that makes Linux cool is hidden to you unless you
A) Learn the CLI, AND
B) Give up the consistant interface of KDE.
Yea, it takes work. Yea, it takes thinking. It means that instead of sitting down and just coding, the KDE and GNOME guys actually have to use their brains and decide how everything fits together. A user environment is a home for the user. People don't like poorly architecture/organized homes (no matter how solidly built) and people don't like poorly architectured DEs (most anyway.) Creating a user environment is like writing a sonnet or a novel. Everything has to have a purpose, parts shouldn't be redundant, everything has to harmonize together. That's the only good way to do it.
With al the effor being expended putting useless features into GNOME and KDE, the Linux crowd could have taken AfterStep or WindowMaker long ago and have shaped Linux into a desktop-worthy OS today. Its a shame that people are working so hard to fix something that isn't the problem.
Linux has so many problems on the desktop it isn't even funny. Sure the basics are there, but it is all so poorly put together that it is quite obvious to anyone why Linux on the mass-market desktop isn't taking off. I think the best thing to do would be to work to polish Linux up. Forget about putting more nifty features in the DEs, creating four different filesystems, a browser that rivels Emacs in overkill factor and get the basics done. For example:
1) Polish up X. 4.0 was a huge leap forward for people in terms of usability, but it still needs work. First, get a GUI to configure it. Relying on a text file to configure something like inetd is one thing; it is so complex that a GUI would be very confusing. However, XFree86Config has so little in it, a GUI should be no problem! All it does is specify a list of modules, specify fontpaths, and set some options for input/output devices. It would be a piece of cake to totally wrap all the features of xf86config (XF86Setup still hasn't been updated yet, AIRC) into a nice GUI program. Second, make it as usable as every other GUI interface in existance. Every single GUI I've ever used, (BeOS, all flavors of Windows since 3.0, QNX Photon, OS/2) have let you choose an exact refresh rate. Why the hell can't X do it? (The sad part is that it probably can, but in the last hour that i've been trying, I can find neither the documentation that says so, nor does anything that comes with the X distro tell me how to do so. Maybe I should read the source?) Hell, even accelerated X lets you set the exact refresh rate! Why can't X change the resolution on the fly? You wouldn't believe how useful BeOS's seperate workspace/seperate res setting is. It helps when you're doing graphics work, when you're doing web work, and even when you're gaming. Set one of the 32 workspaces to a certain resoluation and just switch to that and load your 640x480 game. Lastly, speed it up. Again, 4.0 has made huge strides in this area, but it is still not good enough. The sad part is that the X guys are probably the ones who most "get" what is wrong with Linux on the desktop and are working to fix it.
2) Get a standard DE API. Its great that there are all sorts of UIs out there, that's not a problem. What IS a problem is that there are different APIs for them. All software should be coded for one GUI API, and the window manager should interpret that as necessary. It is totally horrible to anyone with any sense of cleanliness to see the mess that is the miasma of libraries that makes up a common Linux system. You've got TclX, KDE, GNOME, OpenStep, straight-X, Motif, FLTK, etc. That is ugly, ass-ugly. It also makes Linux take up as much RAM as Win2K. That is simply wrong. Not only that, it is confusing. Mandrake installs dozens of different apps that do the same thing, but use different UIs. For example, you can get XCDRoast (ugly UI), gnometoaster (I don't use GNOME) or cdrecord (CLI, hah!) In an ideal world, there would be one GUI API and no matter what desktop you used, it would work. I liked the way it was in the pre enlightenment era when apps weren't tied to DEs. All apps worked on WindowMaker, FVWM, MWM, etc without extra libraries, and with the same (butt-ugly) straight-X interface. Sure you can run a GNOME app in KDE, but it still quacks like a GNOME app, waddles like a GNOME app, and tastes like a GNOME app. (I dislike duck, chicken is best.)
3) Make the advanced features of Linux more accessible. All the cool features that make Linux worthwhile to switch too are often hidden to the average user. If you run KDE, the only thing you gain over running Windows is more stability. All the stuff that makes Linux cool is hidden to you unless you
A) Learn the CLI, AND
B) Give up the consistant interface of KDE.
Yea, it takes work. Yea, it takes thinking. It means that instead of sitting down and just coding, the KDE and GNOME guys actually have to use their brains and decide how everything fits together. A user environment is a home for the user. People don't like poorly architecture/organized homes (no matter how solidly built) and people don't like poorly architectured DEs (most anyway.) Creating a user environment is like writing a sonnet or a novel. Everything has to have a purpose, parts shouldn't be redundant, everything has to harmonize together. That's the only good way to do it.
With al the effor being expended putting useless features into GNOME and KDE, the Linux crowd could have taken AfterStep or WindowMaker long ago and have shaped Linux into a desktop-worthy OS today. Its a shame that people are working so hard to fix something that isn't the problem.
Standards have to be set somewhere. Two political parties and two DE's are not the same. You can switch political parties without totally restructuring the country. Switch DE's and you might as well be running a different OS.
1) Why should NVIDIA OSS their drivers? You do realize that an OpenGL driver is a *COMPLETE* implementation of the OpenGL pipeline, not just hardware specs. Designing a GL driver is hard. Matrox, ATI, NEC, everyone is having problems with their GL drivers. Why the hell should NVIDIA help them out?
2) Bitching at other people to open drivers is not the OSS way. The OSS way is
A) Reverse engineering the specs and writing your own driver, OR
B) Design your own damn hardware and OSS those drivers.
Remember, NVIDIA is a CORPORATION. They don't have to, and SHOULDN'T care about the users, UNLESS it servers their interests. NVIDIA pays good attention to users because it allows them to stay on top in the graphics industry. I have never had a problem with an NVIDIA card (if you bought early-gen Athlons or cheapo Socket7 AGP boards, that's your own damn fault) and ever since the early days of the TNT (after the first few driver releases) their drivers have been totally solid. They're also one of the main reasons why Win98 seems plausibly stable to me.
So quit your bitching and try to see it from their point of view. If they see that there is more money to be made through OSS drivers, and it does come down to money in our society*, then they'll OSS the drivers.
* That's how capitalism works. Companies making lots of money is GOOD for the people. Bitch about MS all you want, if it hadn't been for them, the economy wouldn't be nearly as good as it is today.
PS: Yea, I know NVIDIA isn't giving BeOS the specs to build 3D drivers. Yes it does suck. No its not the same as asking them to OSS their drivers. BeOS GL drivers would be under NDA, Be would write the drivers, and nobody would know NVIDIA's secrets. Methinks that the main reason we're not seeing BeOS OpenGL drivers is that NVIDIA is in bed with SGI and SGI is trying to protect its Linux initiative.
Of course, if you're computer is less than 4 years, old, its sucking up 10w for 2/3s of the day. (Unless you use it more than 8h/day) So immediatly, your figure of 140 drops to ~50. Then you factor in the fact that you probably don't use it every day, and you've got ~40 or so. So, I underballed it, the actual figure is more like 80-something under your usage load. For me however (maybe, 3-4 hours at most) with a lesser set of monitors, the cost should be around $30 or so.
Good god. The average PC chews up about a high-power lightbulb or two's worth of power (My room as a 200W halogen bulb). If you can afford a PC, you can afford the electricity to run it. (around $20 a year)
If you hadn't noticed, NVIDIA's cards (GeForce2 GTS, GeForce2 MX) are LESS expensive than the comparable ATI models (Radeon DDR 64MB, Radeon SDR 32MB) Not only that, but performance is mucho better.
A) C++ is only inherently more bloated because the standard library is bigger. It is slower because of language features like virtual functions. Otherwise, similar C an C++ code are about the same in performance.
B) When was the last time you saw a compiler that did only C?
C) The debugging arguement is iffy. If you do it right, C++ is only marginally harder to debug than C.
D) An idiot coder will shot himself in the foot whether you give them a 9mm pistol (C) or an Uzi (C++)
E) You forget to mention some of the advantages C++ has. It is a good deal more structured, and some of the automatic stuff is very useful. For example, I'm messing around with a USB joystick driver. I needed a structure to keep track of information for non-linier joysticks (MS Sidewinder) If I had been able to use C++, I could just edit the contructor to set my pointer to NULL, and edit the destructor to free the corrections structure. Instead, I had to look through the whole code for everywhere the structure was destroyed and fix it manually.
What's wrong with C++. It's not like Qt is based on multiple inherited, RTTI & exception-using, virtual iterators. A lot of it is just like C with looser variable declaration rules and structures that contain functions. There is nothing inherntly bloated about C++, its all a matter of what your application uses. Ideally, the development platform for this would use a subset of C++, with STL, RTTI, and exceptions disabled. By getting rid of some of the obscure aspects of the language (which you shouldn't be using anyway unless you have a damn good reason) you can get something more structured than C, without the bloat often found in C++.
Getting a port of this to the desktop would be seriously cool. Finally, you can mate the selvte Linux kernel to the svelte embedded Qt library instead of X + Qt +KDE and not end up with an ugly bastard child. However, one thing bothers me. If Qt/embedded works with the frame buffer, it means it doesn't use hardware acceleration. That's a travasty! I mean with a little work, this could be so much better (since KDE apps are enough to make a decent system) (for many users) than the system we have today. Are there any plans to allow a hardware acceleration architecture here? I mean QNX Photon does hardware acceleration on a lot of graphics cards, and I'm pretty sure that a lot of embedded systems contain some form of acceleration in their video chips.
All bodies orbit around a commen point in space, the common center of mass. The sun and earth do it to. If you look at the sun over a long period of time, it will look like its wobbling because it is orbiting around a point thats not exactly at its own center (though, given the mass of the Sun, its pretty damn close.) The common point that the moon and Earth orbit around is about a thousand miles under the surface of the earth, so you can still say that the moon orbits around the earth. If it were outside the earth, then it might make more sense to call it a binary system.
Legecy support is a bitch. People are too damn afraid to abondon these things. I think that there should be a 7 year limit on how long software should be supported. There is really no reason to want to run old software and hardware on new environments/hardware.
I don't know how effective this will be, because the whole reason we use computers is to get AWAY from the desk. I mean my desk is always crammed with papers, book ets, why would I want that clutter in my computer? (Another reason I hate the UNIX directory structure!) I really do think the UI of the future is VOICE control. Think about it, even in real life, the easiest thing to do is have somebody else do your work. No file manager will ever be easier than the user just asking (or in the future, THINGING) for the report he was working on. No "Start Menu" will ever be easier than the user simply asking "Open-up Opera," or, "I need to use 3D Studio." Another thing that is imporant is tactile response. Almost as much as visual, humans are tactile creatures; they like to touch things. Integrating touch and voice into the environment, IMO, is much more effective than 3D spaces.
That's 12x speeds but this is far higher density than a CD. Take a look at what their website says:
>>>>>>>>>>>>>>>>>>>>>>
Quick Parallel Access and Retrieval of Information
Reading from several layers at a time and multiple tracks at a time - nearly impossible using the
reflective technology of a CD/DVD - is easily achieved in FMD. This will allow for retrieval speeds of up
to 1 gigabit/second.
>>>>>>>>>>>>>>>>>>>>>>
That's 125MB/sec. That number is quite believable. Consider this: a 1X DVD-ROM drive transfers at about 8X in CDROM terms. That's a linier increase with with desnsity (a DVD is about 7 times more dense than a CD-ROM). Now if you take the speed of the fastest CD-ROM drive, the Kenwood 72X (which uses multiple lasers to read a single layer, while this drive reads multiple layers) it has a sustained transfer rate of around 10MB/sec. If you apply the 8X increase you get from the inreased density (a layer of these discs is the same density as a DVD disc) then you get something in the neighborhood of 80MB/sec sustained. This jibes with the markting-speak figure of 125MB/sec. As soon as the Kenwood DVD drives with multiple-beam pickup come out, you should see a good indication of what these 140GB drives will be able to transfer at.
Slashdot Mirror
1) Speed is already one of the most emphasized design goals of the Linux kernel. If you have never read the Linux kernel source, then you're probably not aware of the numerous gcc-specific tricks and tangled code that is used to speed optimizations. Trust me. The kernel is as fast as it's going to get.
.so) into the proper directory. It doesn't get any damn easier.
>>>>>>>>>>>>>>>>>
I know the kernel does a good job with speed. However, it is NEVER fast enough. There is always some more tuning that can be done, somewhere.
2) It is standardized between every incremental revision, as much as any driver model can be standardized. The major changes only come between minor and major revisions, such
as 2.2 -> 2.3/2.4.
>>>>>>>>>>>>
It is not "officially" standardize. Stuff can, and does break. The NVIDIA kernel drivers broke three times over the period of a few kernels. That's not good. If there was an official decree that "all 2.4.X" kernels will have a standard driver interface, then you wouldn't have to worry about breaking drivers until the next rev rolled around in 2 years.
3) Whatever.
>>>>>>
Good god, subtlety is lost on you people. Didn't the smiley face give away the fact that I was kidding!
4) Nonsense. The kernel uses the user-level helper tasks for efficiency's sake. If you haven't studied the kernel module loading system, then you shouldn't really be talking about it. Standardization of config files is also impossible in many cases do to the differences between said devices.
>>>>>>>>>>>>>>>>>>>>>
I really don't see how config files can't be standardized. The XML stuff floating around on this discussion sounds like a great idea. Also, using user-level processes to load drivers is a stupid idea. BeOS has by far the best driver loading sheme of any OS out there (OSs that don't have Quake ports are excluded) The system takes care of system stuff (loading drivers) and you only have to get involved when something goes wrong (rare.) Installing new drivers amounts to copying an add-on (a dynamically loaded
5) Might be nice.
6) Okay, now this just shows total ignorance of how Linux and software/system interaction in general works. The kernel's treatment of threads is that they are equal to processes that share the same memory mapping structures. The Linux scheduler handles thread-switching quite admirably, and you will be hard-pressed to find any desktop OS scheduler that performs as well as Linux's. The major misconception here is in assuming that "pervasive multi-threading" is all the kernel's responsibility. That is all the responsibility of the
user-level library and application code. The kernel schedules and relegates threads. It's the user-level code that responsible for taking advantage of the threading facilities
available.
>>>>>>>>>>>>>>>>>
It's not the kernel responsibility, but unless the kernel itself is super thread friendly (multi-threading the kernel itself helps in this respect) it is harder to make multi-threaded apps. Also, the kernel can "force" multi threading on apps in which it is useful.
You seem to be bound up in the desktop world of "GUI == part of OS." In Linux, the GUI is a user-level application, as well it should be in the case of what they have available.
>>>>>>>>>
How do you derive that? The OS that I use 90% of the time has NETWORKING in userspace.
God forbid anyone attempt to weld the Unseelie monstrosity that is X11 into the kernel. That would introduce bloat and instability into the entire system.
>>>>>>>>>>
yea, that's why it is abad idea!
This is why there
aren't kernel-level SAMBA implementations, BTW. The responsiveness of the desktop interface is not the Linux kernel's fault. The fact is that QNX and BeOS both have very well written GUI layers.
>>>>>>>>>>>>
As I said, the kernel can force correct behavior. Also, I'm not only talking GUI here, BeOS has audio latencies that approach that of RTLinux, and the context-switch/event response times for QNX blow everything else out of the water. Trust me, there is room for the kernel to improve.
However, to claim that they are in general more responsive is a little bit of marketing/evangelism propoganda. The responsiveness of the Linux kernel is
very, very nice on a process/thread level.
>>>>>>>>
It is very, very nice. Just not as nice as some of the other OSs out there. Given the volume of talent devoted to Linux, there is no reason Linux's response shouldn't exceed that of those other OSs.
2) If the standard is designed correctly only the occasional device would need to break it. I mean there isn't much difference at the driver level, an ethernet driver is an ethernet driver, and there is no reason to change it between minor revision. It doesn't happen much anyway, but I think making it an official policy would keep drivers from breaking. Take, for example, the fact that the NVIDIA kernel interface broke three or four times. That is really too much.
3) I was kidding. I know, subtlety is hard.
4) Automatic loads != no choice. It simply means that you don't have to fuss with it unless you want to. In BeOS, if you want to load a different driver, then you just mv the old driver out of the driver directory heirarchy and substitute the new one. If you need to change the default parameters, you can edit the driver config file (each driver that has configurable parameters has a paired config file that uses a fairly standard parsing method across different drivers) The point is, that you don't have to hand control unless you want to.
5) Then fix ALSA. There should be only ONE low-level Linux sound API.
6) Agreed. Its a wonder that Linux doesn't take better advantage of its OSS nature by specializing kernels. It would even be possible to keep the APIs the same, so different, compatible, kernels could be tuned for different tasks. It would take more work, but isn't the huge number of programmers one of the advantages of OSS?
The registry isn't the thing that's bloated, its the apps that use the registry irresponsbily. The apps that leave dead wood lying around and write to wrong keys. The problem persists wheter or not that feature is in Linux.
The sysadmins need to get their heads out of their asses and learn something new? And if they aren't, they should probably be using Windows. How many times have you heard the argument, "Linux is different, users should learn how to use it!" The same thing should apply for sysadmins.
1) Speed it up. The kernel already does a great job with speed, but don't trade speed for gee-wiz features that 1% of the population uses. That's what third party patches are for. Keep the standard kernel as general/lightweight as possible.
;)
2) Standardize the driver interface. Yea, it takes actual thinking to come up with a good interface and stick with it, but it would only have to hold between major version changes (a nice trade-off between a single driver interface forever) and you really shouldn't be changing the driver interface between 2.4.1 and 2.4.18 anyway.
3) Put hooks in to only allow KDE to run. Although methinks that's not going to happen anytime soon
4) Standardize configuration. modules.conf, moduels.rc and all of the config programs (iptables, ipchains, etc) are too much. Get rid of modeprobe, kerneld, etc, and have the kernel automatically load modules itself, maybe with some help from config files. BeOS can automatically load the correct drivers for its hardware and there is no reason Linux shouldn't be able to do the same. Finally, standardize the configuaration of kernel modules. All kernel modueles, from iptables to joystick drivers should be configured the same way, either through a strict hierarchy of config files, or through a standard program.
5) Replace OSS with ALSA and tie it to the standard configuaration mode discussed above. I know they're working on that, any idea when it will be finished?
6) Make it more thread rather than process oriented. Make it totally reentrant, and make it highly multi-threaded. As anyone whose used BeOS will tell you, "pervasive multi-threading" is far more than just a buzz-word. QNX, AtheOS, and BeOS are all highly multi-threaded and are three of the most responsive desktop OSs available. That's no coincidence.
Standardization != lack of choices. If you hadn't noticed, cars have become incredibly standardized these days, yet nobody complains that there aren't enough choices. Or take graphics cards. Everybody has standardized on D3D/OpenGL interfaces, and yet there are still tons of choices. Or soundcards, everyone uses DSound3D w/ EAX, yet I still can't decide whether to get one of the new fangled cards or stick with a good old SBLive!. I really doubt anybody would care whether a distro uses .debs or .RPMS. Pick the best one and stick with. Standardize the directory layout. Standardize the config file layout. Set a minimum level of software (that will means kernels will have to become totally compatible at the driver level between 2.X.Y versions. Meaning drivers from 2.4.0 should work flawlessly without recompilation on 2.4.17) Specify that any new distro adhering to the Linux 2.4 standard needs to have a 2.4 compatible kernel, a glibc 2.0.3 compatible c-library, ncurses 5.0 compatible ncurses library, etc. Nobody really gives a flying f*ck what version their ncurses library is, so why not standardize it? Specify a standard set of libraries so joe's-own-stupid-library.so.56 can be left out of distros. Standardize on Perl or Python (pick one dammit!) for config scripts so other stuff didn't have to be installed. Standardize on bash (or tcsh or zsh or whatever) for shell scripts and stick with it. None of this prevents any user from using whatever they want, it just forces developers (developers don't have nearly as many rights as they think they do) to standardize on one set of programs so users who don't use other things don't need to have them installed. Once you set up a baseline, then the distro makers are free to do whatever they bloody well want. Slackware can continue to balance performance/modernness for stability, Debian can contiue to use the oldest, stablest software possible (as long as it meets the baseline), and Suse can continue to stuff 2.X-pre1-ac1 kernels into its distros. Most of the concessions the distro makers would have to make really wouldn't affect anybody that much. Unless of course you cannot stand the thought of KDE in /usr, in which case you could always use a non-standard distro.
embedded: QNX, Beos
>>>>>>>>>>
You do realize that BeOS is a desktop OS and not an embedded one? BeIA is probably what you're referring to. In the embedded market, there are MANY other OSs besides QNX and BeOS. These two are probably best for stuff like handhelds or web pads, but you go into the automated machinery OSs and these two don't cut it.
workstation: w2k,
>>>>>>>>>
Huh, funny. NT4 kicks Win2K's ass all over the place on the workstation. If it fits right (ie its got the software you want), then BeOS also makes a great workstation OS. Linux also makes a pretty decent workstation OS that's getting better everyday.
small office server: w2k, novell, osX
>>>>>>>>>>
osx-server is totally unproven. Win2K is easy to admin, but Linux, FreeBSD or Novell are probably best here.
web server: *BSD, w2k
>>>>>>>>>>>>>>>
Agreed, but Linux can do this too.
realtime: Inferno, QNX
>>>>>>>>>>>
Who actually uses Inferno? QNX is good but there are a lot of other hard realtime OSs that are better depending on the use. In this catagory, the OS is so use dependant, that you can't classify any one OS as the best.
games: w2k (+aka "whistler")
>>>>>>>>
Bullshit. Win95 all the way. Win98 is slower and more unstable, Millenium is significantly slower, and Win2K's OpenGL support is crappy. If you're games run well in OpenGL, then NT4 kicks everything's ass as a game OS. When more games get ported to BeOS (and if the OpenGL is as good as the previews show it to be) then BeOS will also be competitive as a gaming OS.
Good grief, /. changes the default posting mode every day? (Or is it just a concpiracy. Does /. detect NetPositive and go about screwing hapless BeOS users?)
Linux has so many problems on the desktop it isn't even funny. Sure the basics are there, but it is all so poorly put together that it is quite obvious to anyone why Linux on the mass-market desktop isn't taking off. I think the best thing to do would be to work to polish Linux up. Forget about putting more nifty features in the DEs, creating four different filesystems, a browser that rivels Emacs in overkill factor and get the basics done. For example:
1) Polish up X. 4.0 was a huge leap forward for people in terms of usability, but it still needs work. First, get a GUI to configure it. Relying on a text file to configure something like inetd is one thing; it is so complex that a GUI would be very confusing. However, XFree86Config has so little in it, a GUI should be no problem! All it does is specify a list of modules, specify fontpaths, and set some options for input/output devices. It would be a piece of cake to totally wrap all the features of xf86config (XF86Setup still hasn't been updated yet, AIRC) into a nice GUI program. Second, make it as usable as every other GUI interface in existance. Every single GUI I've ever used, (BeOS, all flavors of Windows since 3.0, QNX Photon, OS/2) have let you choose an exact refresh rate. Why the hell can't X do it? (The sad part is that it probably can, but in the last hour that i've been trying, I can find neither the documentation that says so, nor does anything that comes with the X distro tell me how to do so. Maybe I should read the source?) Hell, even accelerated X lets you set the exact refresh rate! Why can't X change the resolution on the fly? You wouldn't believe how useful BeOS's seperate workspace/seperate res setting is. It helps when you're doing graphics work, when you're doing web work, and even when you're gaming. Set one of the 32 workspaces to a certain resoluation and just switch to that and load your 640x480 game. Lastly, speed it up. Again, 4.0 has made huge strides in this area, but it is still not good enough. The sad part is that the X guys are probably the ones who most "get" what is wrong with Linux on the desktop and are working to fix it.
2) Get a standard DE API. Its great that there are all sorts of UIs out there, that's not a problem. What IS a problem is that there are different APIs for them. All software should be coded for one GUI API, and the window manager should interpret that as necessary. It is totally horrible to anyone with any sense of cleanliness to see the mess that is the miasma of libraries that makes up a common Linux system. You've got TclX, KDE, GNOME, OpenStep, straight-X, Motif, FLTK, etc. That is ugly, ass-ugly. It also makes Linux take up as much RAM as Win2K. That is simply wrong. Not only that, it is confusing. Mandrake installs dozens of different apps that do the same thing, but use different UIs. For example, you can get XCDRoast (ugly UI), gnometoaster (I don't use GNOME) or cdrecord (CLI, hah!) In an ideal world, there would be one GUI API and no matter what desktop you used, it would work. I liked the way it was in the pre enlightenment era when apps weren't tied to DEs. All apps worked on WindowMaker, FVWM, MWM, etc without extra libraries, and with the same (butt-ugly) straight-X interface. Sure you can run a GNOME app in KDE, but it still quacks like a GNOME app, waddles like a GNOME app, and tastes like a GNOME app. (I dislike duck, chicken is best.)
3) Make the advanced features of Linux more accessible. All the cool features that make Linux worthwhile to switch too are often hidden to the average user. If you run KDE, the only thing you gain over running Windows is more stability. All the stuff that makes Linux cool is hidden to you unless you
A) Learn the CLI, AND
B) Give up the consistant interface of KDE.
Yea, it takes work. Yea, it takes thinking. It means that instead of sitting down and just coding, the KDE and GNOME guys actually have to use their brains and decide how everything fits together. A user environment is a home for the user. People don't like poorly architecture/organized homes (no matter how solidly built) and people don't like poorly architectured DEs (most anyway.) Creating a user environment is like writing a sonnet or a novel. Everything has to have a purpose, parts shouldn't be redundant, everything has to harmonize together. That's the only good way to do it.
With al the effor being expended putting useless features into GNOME and KDE, the Linux crowd could have taken AfterStep or WindowMaker long ago and have shaped Linux into a desktop-worthy OS today. Its a shame that people are working so hard to fix something that isn't the problem.
Linux has so many problems on the desktop it isn't even funny. Sure the basics are there, but it is all so poorly put together that it is quite obvious to anyone why Linux on the mass-market desktop isn't taking off. I think the best thing to do would be to work to polish Linux up. Forget about putting more nifty features in the DEs, creating four different filesystems, a browser that rivels Emacs in overkill factor and get the basics done. For example: 1) Polish up X. 4.0 was a huge leap forward for people in terms of usability, but it still needs work. First, get a GUI to configure it. Relying on a text file to configure something like inetd is one thing; it is so complex that a GUI would be very confusing. However, XFree86Config has so little in it, a GUI should be no problem! All it does is specify a list of modules, specify fontpaths, and set some options for input/output devices. It would be a piece of cake to totally wrap all the features of xf86config (XF86Setup still hasn't been updated yet, AIRC) into a nice GUI program. Second, make it as usable as every other GUI interface in existance. Every single GUI I've ever used, (BeOS, all flavors of Windows since 3.0, QNX Photon, OS/2) have let you choose an exact refresh rate. Why the hell can't X do it? (The sad part is that it probably can, but in the last hour that i've been trying, I can find neither the documentation that says so, nor does anything that comes with the X distro tell me how to do so. Maybe I should read the source?) Hell, even accelerated X lets you set the exact refresh rate! Why can't X change the resolution on the fly? You wouldn't believe how useful BeOS's seperate workspace/seperate res setting is. It helps when you're doing graphics work, when you're doing web work, and even when you're gaming. Set one of the 32 workspaces to a certain resoluation and just switch to that and load your 640x480 game. Lastly, speed it up. Again, 4.0 has made huge strides in this area, but it is still not good enough. The sad part is that the X guys are probably the ones who most "get" what is wrong with Linux on the desktop and are working to fix it. 2) Get a standard DE API. Its great that there are all sorts of UIs out there, that's not a problem. What IS a problem is that there are different APIs for them. All software should be coded for one GUI API, and the window manager should interpret that as necessary. It is totally horrible to anyone with any sense of cleanliness to see the mess that is the miasma of libraries that makes up a common Linux system. You've got TclX, KDE, GNOME, OpenStep, straight-X, Motif, FLTK, etc. That is ugly, ass-ugly. It also makes Linux take up as much RAM as Win2K. That is simply wrong. Not only that, it is confusing. Mandrake installs dozens of different apps that do the same thing, but use different UIs. For example, you can get XCDRoast (ugly UI), gnometoaster (I don't use GNOME) or cdrecord (CLI, hah!) In an ideal world, there would be one GUI API and no matter what desktop you used, it would work. I liked the way it was in the pre enlightenment era when apps weren't tied to DEs. All apps worked on WindowMaker, FVWM, MWM, etc without extra libraries, and with the same (butt-ugly) straight-X interface. Sure you can run a GNOME app in KDE, but it still quacks like a GNOME app, waddles like a GNOME app, and tastes like a GNOME app. (I dislike duck, chicken is best.) 3) Make the advanced features of Linux more accessible. All the cool features that make Linux worthwhile to switch too are often hidden to the average user. If you run KDE, the only thing you gain over running Windows is more stability. All the stuff that makes Linux cool is hidden to you unless you A) Learn the CLI, AND B) Give up the consistant interface of KDE. Yea, it takes work. Yea, it takes thinking. It means that instead of sitting down and just coding, the KDE and GNOME guys actually have to use their brains and decide how everything fits together. A user environment is a home for the user. People don't like poorly architecture/organized homes (no matter how solidly built) and people don't like poorly architectured DEs (most anyway.) Creating a user environment is like writing a sonnet or a novel. Everything has to have a purpose, parts shouldn't be redundant, everything has to harmonize together. That's the only good way to do it. With al the effor being expended putting useless features into GNOME and KDE, the Linux crowd could have taken AfterStep or WindowMaker long ago and have shaped Linux into a desktop-worthy OS today. Its a shame that people are working so hard to fix something that isn't the problem.
Doh!
Standards have to be set somewhere. Two political parties and two DE's are not the same. You can switch political parties without totally restructuring the country. Switch DE's and you might as well be running a different OS.
1) Why should NVIDIA OSS their drivers? You do realize that an OpenGL driver is a *COMPLETE* implementation of the OpenGL pipeline, not just hardware specs. Designing a GL driver is hard. Matrox, ATI, NEC, everyone is having problems with their GL drivers. Why the hell should NVIDIA help them out?
2) Bitching at other people to open drivers is not the OSS way. The OSS way is
A) Reverse engineering the specs and writing your own driver, OR
B) Design your own damn hardware and OSS those drivers.
Remember, NVIDIA is a CORPORATION. They don't have to, and SHOULDN'T care about the users, UNLESS it servers their interests. NVIDIA pays good attention to users because it allows them to stay on top in the graphics industry. I have never had a problem with an NVIDIA card (if you bought early-gen Athlons or cheapo Socket7 AGP boards, that's your own damn fault) and ever since the early days of the TNT (after the first few driver releases) their drivers have been totally solid. They're also one of the main reasons why Win98 seems plausibly stable to me.
So quit your bitching and try to see it from their point of view. If they see that there is more money to be made through OSS drivers, and it does come down to money in our society*, then they'll OSS the drivers.
* That's how capitalism works. Companies making lots of money is GOOD for the people. Bitch about MS all you want, if it hadn't been for them, the economy wouldn't be nearly as good as it is today.
PS: Yea, I know NVIDIA isn't giving BeOS the specs to build 3D drivers. Yes it does suck. No its not the same as asking them to OSS their drivers. BeOS GL drivers would be under NDA, Be would write the drivers, and nobody would know NVIDIA's secrets. Methinks that the main reason we're not seeing BeOS OpenGL drivers is that NVIDIA is in bed with SGI and SGI is trying to protect its Linux initiative.
Why in god's named you turn APM off?
Of course, if you're computer is less than 4 years, old, its sucking up 10w for 2/3s of the day. (Unless you use it more than 8h/day) So immediatly, your figure of 140 drops to ~50. Then you factor in the fact that you probably don't use it every day, and you've got ~40 or so. So, I underballed it, the actual figure is more like 80-something under your usage load. For me however (maybe, 3-4 hours at most) with a lesser set of monitors, the cost should be around $30 or so.
3 years ago, the fastest chip on the market was a PII300. At a $1200 pricetag no less.
Good god. The average PC chews up about a high-power lightbulb or two's worth of power (My room as a 200W halogen bulb). If you can afford a PC, you can afford the electricity to run it. (around $20 a year)
Actually, the refresh rate of an Active Matrix screen is around 100hz (I think, at least it should be capable of that.)
If you hadn't noticed, NVIDIA's cards (GeForce2 GTS, GeForce2 MX) are LESS expensive than the comparable ATI models (Radeon DDR 64MB, Radeon SDR 32MB) Not only that, but performance is mucho better.
A) C++ is only inherently more bloated because the standard library is bigger. It is slower because of language features like virtual functions. Otherwise, similar C an C++ code are about the same in performance.
B) When was the last time you saw a compiler that did only C?
C) The debugging arguement is iffy. If you do it right, C++ is only marginally harder to debug than C.
D) An idiot coder will shot himself in the foot whether you give them a 9mm pistol (C) or an Uzi (C++)
E) You forget to mention some of the advantages C++ has. It is a good deal more structured, and some of the automatic stuff is very useful. For example, I'm messing around with a USB joystick driver. I needed a structure to keep track of information for non-linier joysticks (MS Sidewinder) If I had been able to use C++, I could just edit the contructor to set my pointer to NULL, and edit the destructor to free the corrections structure. Instead, I had to look through the whole code for everywhere the structure was destroyed and fix it manually.
What's wrong with C++. It's not like Qt is based on multiple inherited, RTTI & exception-using, virtual iterators. A lot of it is just like C with looser variable declaration rules and structures that contain functions. There is nothing inherntly bloated about C++, its all a matter of what your application uses. Ideally, the development platform for this would use a subset of C++, with STL, RTTI, and exceptions disabled. By getting rid of some of the obscure aspects of the language (which you shouldn't be using anyway unless you have a damn good reason) you can get something more structured than C, without the bloat often found in C++.
Getting a port of this to the desktop would be seriously cool. Finally, you can mate the selvte Linux kernel to the svelte embedded Qt library instead of X + Qt +KDE and not end up with an ugly bastard child. However, one thing bothers me. If Qt/embedded works with the frame buffer, it means it doesn't use hardware acceleration. That's a travasty! I mean with a little work, this could be so much better (since KDE apps are enough to make a decent system) (for many users) than the system we have today. Are there any plans to allow a hardware acceleration architecture here? I mean QNX Photon does hardware acceleration on a lot of graphics cards, and I'm pretty sure that a lot of embedded systems contain some form of acceleration in their video chips.
All bodies orbit around a commen point in space, the common center of mass. The sun and earth do it to. If you look at the sun over a long period of time, it will look like its wobbling because it is orbiting around a point thats not exactly at its own center (though, given the mass of the Sun, its pretty damn close.) The common point that the moon and Earth orbit around is about a thousand miles under the surface of the earth, so you can still say that the moon orbits around the earth. If it were outside the earth, then it might make more sense to call it a binary system.
Legecy support is a bitch. People are too damn afraid to abondon these things. I think that there should be a 7 year limit on how long software should be supported. There is really no reason to want to run old software and hardware on new environments/hardware.
I don't know how effective this will be, because the whole reason we use computers is to get AWAY from the desk. I mean my desk is always crammed with papers, book ets, why would I want that clutter in my computer? (Another reason I hate the UNIX directory structure!) I really do think the UI of the future is VOICE control. Think about it, even in real life, the easiest thing to do is have somebody else do your work. No file manager will ever be easier than the user just asking (or in the future, THINGING) for the report he was working on. No "Start Menu" will ever be easier than the user simply asking "Open-up Opera," or, "I need to use 3D Studio." Another thing that is imporant is tactile response. Almost as much as visual, humans are tactile creatures; they like to touch things. Integrating touch and voice into the environment, IMO, is much more effective than 3D spaces.
That's 12x speeds but this is far higher density than a CD. Take a look at what their website says:
>>>>>>>>>>>>>>>>>>>>>>
Quick Parallel Access and Retrieval of Information
Reading from several layers at a time and multiple tracks at a time - nearly impossible using the
reflective technology of a CD/DVD - is easily achieved in FMD. This will allow for retrieval speeds of up
to 1 gigabit/second.
>>>>>>>>>>>>>>>>>>>>>>
That's 125MB/sec. That number is quite believable. Consider this: a 1X DVD-ROM drive transfers at about 8X in CDROM terms. That's a linier increase with with desnsity (a DVD is about 7 times more dense than a CD-ROM). Now if you take the speed of the fastest CD-ROM drive, the Kenwood 72X (which uses multiple lasers to read a single layer, while this drive reads multiple layers) it has a sustained transfer rate of around 10MB/sec. If you apply the 8X increase you get from the inreased density (a layer of these discs is the same density as a DVD disc) then you get something in the neighborhood of 80MB/sec sustained. This jibes with the markting-speak figure of 125MB/sec. As soon as the Kenwood DVD drives with multiple-beam pickup come out, you should see a good indication of what these 140GB drives will be able to transfer at.