Modern hard drives easily exceed USB 2.0's maximum sustained thoroughput.
Not under real-world conditions.
Things become even worse if you want the speed advantages of any form of RAID.
And to use those things, you buy a PCI card to control them; the differences between FireWire and USB 2.0 for those applications are academic.
I guess you could say that today's shipping laptop drives (those 2.5" buggers) are serviced by USB 2.0. Anything else is faster.
We are talking about laptop drives here. And, besides, what's the alternative? 1394 is no faster. 1394b is somewhat faster, but, then, there are faster versions of USB in the works as well.
I really don't see what all this complaining is about. This new PCMCIA standard gives you PCI and USB 2.0. USB 2.0 is fine for most applications, and if you really want to run a RAID array on your laptop, use the PCI interface.
Unclear to me why they'd trumpet any sort of connection to USB, given the incredibly bad compatibility story it has.
That's just FUD. USB compatibility is excellent, for the kinds of devices for which there are official standards. That includes mass storage, networking, and digital cameras. USB compatibility may not be perfect, but there are also plenty of FireWire, PCI, parallel port, and RS-232c devices that require special drivers.
In different words, USB's "compatibility story" certainly can be improved,b ut I don't see any alternative to USB that comes even close.
Probably for the same reason why you aren't driving a Formula 1 race car to work: it's not necessary, and it's not cost effective.
In different words, with PCI, they have communications at bus-speed covered for the few applications that need it. But for almost all PCMCIA applications (networks, modems, storage, etc.), USB 2.0 is already much faster than what is needed. And USB 2.0 is cheaper and more widely supported than any serial bus alternative.
What's wrong with renaming after a split?
on
MicroBSD Is No More
·
· Score: 1
To be frank, it will be very hard to convince me that this has been an honest mistake, or whatever.
A global search-and-replace of the project name as the first part of splitting an open source project makes a certain degree of sense. After all, you don't want users of the new distribution getting confused. Of course, the MicroBSD project didn't do this right. On the other hand, the complaints about this sound like just more of the kind of language that is already going back and forth between the developers of the various existing BSD distributions.
Here's a prediction: the moment you succeed in making the distinction between "user" and "programmer" disappear, most of your potential users will disappear with it. Almost all of them who are not also programmers (in the old, pre-disappearance-of-the-distinction-between-users -and-programmers, sense), in fact.
I don't see why. Just because they can easily modify and extend something doesn't mean that people have to do it. Microsoft Office, for example, comes with a complete programming environment built in, but users don't seem to mind. In fact, many non-programmers program in it. It's just that such facilities need to become better and need become pervasive.
In systems like Squeak, users can examine, open up, and modify any part of the user interface of any application. Squeak also has a lot of support for user-level scripting and "application" building. Don't get me wrong: it's not ready for prime-time, but it clearly shows a different way of approaching problems. Systems like Hypercard also blur the distinctions between programming and authoring. HTML/XML and the web are going in that direction as well. And systems like Microsoft Word allow people to create "documents as user interfaces".
The point is simply: there are other approaches to building GUIs than the huge and inflexible C/C++ systems people are building now. And if customizability and user-level programming aren't reasons enough, simply the long release cycles and the fact that UI experts can't fix the software themselves are reason enough to look for different approaches.
I find that whole discussion pretty amusing. I mean, both Gnome and KDE are so much in the Windows/Macintosh mold of user interfaces that the differences between them, and between them and Windows/Macintosh seem miniscule and academic. Yes, and by that I am referring to both usability and configurability. Arguing which is "better" in any of those regards seems like a bunch of priests arguing some fine point of Catholic academic dogma.
Come on, guys, it's nice that Gnome and KDE bring a Windows/Macintosh-like desktop to Linux--lots of Windows refugees will be reasonably happy about that. It's also nice that some egregious usability problems, present in earlier desktops, have been fixed. But let's not pretend that there is anything fundamental being done here other than decent software engineering and avoidance of basic usability blunders.
To do substantially better, we will have to jettison the current straight-jacket of separate C/C++ applications and move to entirely new software architectures. And then, the distinction between "configurability" and "programming", between "user" and "programmer" will pretty much disappear.
If finding things like this, or the fact that there are more suns in the universe than grains of sands on earth, doesn't convince religious fundamentalists of evolution, do you think that the discovery of a bunch of microorganisms will convince them?
"Efficiency" and "speed" sound like the excuses people give me for using something ugly and horrible like FVWM95 or twm.
I don't see what's so "horrible" about them. FVWM95 pretty faithfully copies the appearance of Windows95, and twm is a very minimalist style. If you like other themes, icewm offers a lot of choices.
I spend a lot of time using my computer, so it makes for a nicer experience if the colors aren't retina-burning and fonts are nicely smoothed and so forth.
X11 applications, including window managers, almost always give you complete freedom in choosing colors (I generally prefer "neutral", which is something I need to configure specially on a Mac as well). As for font smoothing, it decreases readability, so it is generally not a good idea to enable it. The most readable on-screen fonts are hand-designed, non-scalable bitmap fonts.
I think you are confusing "stylish" with "effective". Many professional tools (cameras, race cars, etc.) aren't stylish or even easy to use, but they are highly effective.
KDE lets you configure lots of eye candy, just like Gnome. And both have some range of behavioral options. But both are really pretty impoverished when it comes to configurability: anything that goes beyond a few options that the developers thought of requires very heavy lifting and changing the sources to sometimes every program that should know about the new behavior.
Contrast that with systems like Squeak, in which every object that is displayed can be inspected, cloned, and modified by the user. While Squeak itself may not be the future (it's a messy research system), it shows that really the line between "configurability" and "programmability" can be blurred, and probably should be blurred.
At the heart of the limitations of systems like KDE and Gnome is the underlying choice of programming language and toolkit. By essentially aping Microsoft Windows and Motif, both systems have painted themselves into the same corner. This is software design for the past, not the future.
In fact, if anything, KDE and Gnome represent regression rather than progress compared to traditional X11 toolkits: X11 toolkits did have simple, general-purpose tools for opening up applications and changing properties, behaviors, and event-handling on the fly (e.g., editres). Traditional X11 toolkits also handled preferences better when applications ran on multiple hosts; these "new" X11 desktops basically just drop the ball on that, giving you the wrong preferences and generally having their inter-application communication fall apart.
In the long term, I expect that the lines between configurability and programming disappear, as GUIs will people give simple, natural capabilities of connecting and customizing applications. What the underlying software technology will be like remains to be seen, but I guarantee you that it won't be based on monster C++ libraries. More likely, it will be something like X11 with X11 properties and a mix of clear-text scripting and XML.
Perhaps another, better approach is to get rid of the BIOS altogether and replace it with an absolutely minimial, fixed bootstrap loader that doesn't try to do anything other than to load bits from a removable flash card into memory and jump to them. Then, BIOS updates could simply consist of plugging in a new flash chip. That would be safe and simple: you'd have two of those chips around: the old, working one, and the new one whose contents you just downloaded from the Internet under your favorite OS. People for whom that is too complicated would just have the new, updated chip mailed to them for a few dollars.
Storing the startup code on something removable has the advantage that it's much easier to guarantee that you always have a working one around, and that you can let arbitrary software fiddle around with the startup code in whatever way it wants. Also, it means that the startup code doesn't have to be stored on disk. With 8M SmartMedia cards in the sub-$10 range (and much cheaper for manufacturers), this seems quite doable, and the additional connectors and interface logic is cheap and simple, too.
In the Intel server world it seems that trend is going away from better BIOSes/OpenFirmware/Etc, and towards smarter and more functional management boards which are computers in their own right, not bound to the host CPU, RAM, and in some cases NIC.
Of course, this is the way many machines used to be built: they had a big, powerful CPU for the actual work, and a small "front-end processor" (FEP) for bootstrap loading and BIOS-like functions.
GUI OSes are kind of crippling for console redirection, though, and most vendors kludge together something using PC Anywhere or other dependent tools. I was told by a Compaq rep that eventually we might see a management controller with the ability to do what some of the KVM-Over-IP people are doing, except natively in the PC management board, providing a remote keyboard/mouse/display functionality
Here, they are reinventing the wheel as well: HTTP/HTML is arguably the best GUI for these kinds of functions. But if something else is needed, VNC would seem like the right choice: a simple and open protocol.
Personally I'm interested in this and it'd be interesting to see it take off and benefit from all the usual mass-production efficiencies, as well as seing it develop more OS-like features (such as perhaps running user-supplied modules).
Sounds like the famous Chinese curse "may you live in interesting times". I don't want my computer to run yet another "interesting" operating system. I like it to bootstrap quickly and quietly into the OS of my choice.
Making web servers bulletproof isn't hard--they are one of the simplest network application you could imagine. Furthermore, these things would only run at boot time, which, if you run a decent OS, should be very, very rare. And even then, they mostly run behind firewalls.
Isn't that what I was saying? The CPU is slower, but if you run a desktop like IceWM or XFCE, its GUI zips right along. You can run a useful, responsive GUI-based Linux system on that kind of hardware.
Note that the 933MHz C3 is disproportionately faster because it (apparently) has a better memory system.
The BIOS should be replaced by another, hardware-vendor supplied GUI--that's just going in the wrong direction. I mean, who is going to talk to this thing? Why should something become easy to use that, if it ever enters the consciousness of the end user, is most likely going to result in the machine being returned for service anyway? Is software or hardware going to come with lengthy instructions for booting into the BIOS and fiddling with endless configuration screends?
"Normal" home users, the kinds of people who might benefit from a GUI, probably don't want to talk to anything other than their main, mainstream OS. And power users and network administrators want the hardware to come with a system that can be scripted, extended, and remotely controlled. And almost everything that needs to be done with the BIOS-replacement should be done from the regular OS, which can leave little scripts in non-volatile areas for what the BIOS-replacement should do when it reboots (as opposed to putting those instructions into the user's brain).
Yes, the BIOS needs a serious overhaul, and, yes, it needs to change a bit in the direction of becoming a better OS. But it should become a better OS that normal users never have to talk to directly. It should become a 32bit/64bit OS that much more than previously accomplishes its magic behind the scenes. If it needs a GUI at all, the GUI should probably consist of a web server (so that the BIOS can be configured over the net) and a built-in, simple web browser, not some Microsoft-wannabe-lookalike.
For one it wouldn't be slower, the VIA C3 is best about 2/3 the performance of a celeron at the same clock rate. So given that Macs tend to perform better than comparable clock speeds, the Mac will typically outperform it.
I have an 800MHz C3 and a 600 MHz iMac (not too different from a 933MHz C3 vs. a 700MHz iBook): the C3 is indeed slower than the iMac in terms of raw CPU performance, but the GUI and applications actually run faster on the C3. Keep in mind that systems X11 were originally developed for machines like 8MHz 68k systems with a few megabytes of RAM. OSX, on the other hand, is really pushing the envelope in terms of system requirements.
VNC is not a replacement for X11. fbvncserver gives you a fixed 240x320 window on your desktop machine (and slowly and without desktop integration at that). X11 allows applications to open individual windows of arbitrary size on the desktop that behave just like any other application running on the desktop.
Since you are part of the KDE project, and since Qt/KDE/Zaurus/TrollTech supporters keep telling us how much better Qt/Embedded is than X11, and how cheap it is, and how efficient it is, and how everybody will gladly port to Qt, and all that, why isn't the KDE project getting rid of X11? Come on, do you lack the courage of your own convictions? Please tell us.
Qtopia is $195, Qt/Embedded, like their desktop products, is of the order of $2k per developer, plus runtime licenses. Since we are talking about Qt/Embedded for desktop apps, presumably, Troll Tech's current desktop pricing structure would apply.
Microsoft simply aren't willing to risk anymore that they will create an OS and find no third party apps for it.
You misunderstood; it was Microsoft that dropped the ball on providing applications for NT/PPC. For example, for Microsoft Office, they just told IBM: "you port it, we can't be bothered". For BackOffice, they told Motorola to port it (as if Motorola had the expertise to do this sort of thing). If Microsoft doesn't lead the way with porting their own applications, why should third party developers?
You've hit the nail on the head there. Microsoft have come to realize (or at least, believe) that they can't rely on any third parties. That's why they do operating systems, programming languages, end-user applications, back office servers, etc.
Of course, that's what they believe. That's because they are brash, insular people with a serious NIH attitude. They'll rather release some poor in-house hack quickly than figure out how to work with other companies or standards bodies. And because they are very, very big, they can get away with it: their broken prereleases may not be popular, but they are sufficient to damage the market for the established standards, and year by year, Microsoft takes over one market after another. Any other company would be bankrupt with such incompetent behavior, but given the Windows monopoly, that kind of incompetence is a successful business strategy for Microsoft.
Slashdot Mirror
Not under real-world conditions.
Things become even worse if you want the speed advantages of any form of RAID.
And to use those things, you buy a PCI card to control them; the differences between FireWire and USB 2.0 for those applications are academic.
I guess you could say that today's shipping laptop drives (those 2.5" buggers) are serviced by USB 2.0. Anything else is faster.
We are talking about laptop drives here. And, besides, what's the alternative? 1394 is no faster. 1394b is somewhat faster, but, then, there are faster versions of USB in the works as well.
I really don't see what all this complaining is about. This new PCMCIA standard gives you PCI and USB 2.0. USB 2.0 is fine for most applications, and if you really want to run a RAID array on your laptop, use the PCI interface.
That's just FUD. USB compatibility is excellent, for the kinds of devices for which there are official standards. That includes mass storage, networking, and digital cameras. USB compatibility may not be perfect, but there are also plenty of FireWire, PCI, parallel port, and RS-232c devices that require special drivers.
In different words, USB's "compatibility story" certainly can be improved,b ut I don't see any alternative to USB that comes even close.
What difference does it make? USB 2.0 is faster than almost any device you might care to connect through it.
Plus, Firewire isn't some much of the hack that USB is
Again, who cares? Both FW and USB2 work fine, and USB2 support in operating systems is really simple (because most of it is just like USB1).
In different words, with PCI, they have communications at bus-speed covered for the few applications that need it. But for almost all PCMCIA applications (networks, modems, storage, etc.), USB 2.0 is already much faster than what is needed. And USB 2.0 is cheaper and more widely supported than any serial bus alternative.
A global search-and-replace of the project name as the first part of splitting an open source project makes a certain degree of sense. After all, you don't want users of the new distribution getting confused. Of course, the MicroBSD project didn't do this right. On the other hand, the complaints about this sound like just more of the kind of language that is already going back and forth between the developers of the various existing BSD distributions.
I don't see why. Just because they can easily modify and extend something doesn't mean that people have to do it. Microsoft Office, for example, comes with a complete programming environment built in, but users don't seem to mind. In fact, many non-programmers program in it. It's just that such facilities need to become better and need become pervasive.
The point is simply: there are other approaches to building GUIs than the huge and inflexible C/C++ systems people are building now. And if customizability and user-level programming aren't reasons enough, simply the long release cycles and the fact that UI experts can't fix the software themselves are reason enough to look for different approaches.
Come on, guys, it's nice that Gnome and KDE bring a Windows/Macintosh-like desktop to Linux--lots of Windows refugees will be reasonably happy about that. It's also nice that some egregious usability problems, present in earlier desktops, have been fixed. But let's not pretend that there is anything fundamental being done here other than decent software engineering and avoidance of basic usability blunders.
To do substantially better, we will have to jettison the current straight-jacket of separate C/C++ applications and move to entirely new software architectures. And then, the distinction between "configurability" and "programming", between "user" and "programmer" will pretty much disappear.
This means great spring skiing conditions on Mars. Just bring your breathing mask and some warm clothing.
If finding things like this, or the fact that there are more suns in the universe than grains of sands on earth, doesn't convince religious fundamentalists of evolution, do you think that the discovery of a bunch of microorganisms will convince them?
I don't see what's so "horrible" about them. FVWM95 pretty faithfully copies the appearance of Windows95, and twm is a very minimalist style. If you like other themes, icewm offers a lot of choices.
I spend a lot of time using my computer, so it makes for a nicer experience if the colors aren't retina-burning and fonts are nicely smoothed and so forth.
X11 applications, including window managers, almost always give you complete freedom in choosing colors (I generally prefer "neutral", which is something I need to configure specially on a Mac as well). As for font smoothing, it decreases readability, so it is generally not a good idea to enable it. The most readable on-screen fonts are hand-designed, non-scalable bitmap fonts.
I think you are confusing "stylish" with "effective". Many professional tools (cameras, race cars, etc.) aren't stylish or even easy to use, but they are highly effective.
Contrast that with systems like Squeak, in which every object that is displayed can be inspected, cloned, and modified by the user. While Squeak itself may not be the future (it's a messy research system), it shows that really the line between "configurability" and "programmability" can be blurred, and probably should be blurred.
At the heart of the limitations of systems like KDE and Gnome is the underlying choice of programming language and toolkit. By essentially aping Microsoft Windows and Motif, both systems have painted themselves into the same corner. This is software design for the past, not the future.
In fact, if anything, KDE and Gnome represent regression rather than progress compared to traditional X11 toolkits: X11 toolkits did have simple, general-purpose tools for opening up applications and changing properties, behaviors, and event-handling on the fly (e.g., editres). Traditional X11 toolkits also handled preferences better when applications ran on multiple hosts; these "new" X11 desktops basically just drop the ball on that, giving you the wrong preferences and generally having their inter-application communication fall apart.
In the long term, I expect that the lines between configurability and programming disappear, as GUIs will people give simple, natural capabilities of connecting and customizing applications. What the underlying software technology will be like remains to be seen, but I guarantee you that it won't be based on monster C++ libraries. More likely, it will be something like X11 with X11 properties and a mix of clear-text scripting and XML.
Storing the startup code on something removable has the advantage that it's much easier to guarantee that you always have a working one around, and that you can let arbitrary software fiddle around with the startup code in whatever way it wants. Also, it means that the startup code doesn't have to be stored on disk. With 8M SmartMedia cards in the sub-$10 range (and much cheaper for manufacturers), this seems quite doable, and the additional connectors and interface logic is cheap and simple, too.
Of course, this is the way many machines used to be built: they had a big, powerful CPU for the actual work, and a small "front-end processor" (FEP) for bootstrap loading and BIOS-like functions.
GUI OSes are kind of crippling for console redirection, though, and most vendors kludge together something using PC Anywhere or other dependent tools. I was told by a Compaq rep that eventually we might see a management controller with the ability to do what some of the KVM-Over-IP people are doing, except natively in the PC management board, providing a remote keyboard/mouse/display functionality
Here, they are reinventing the wheel as well: HTTP/HTML is arguably the best GUI for these kinds of functions. But if something else is needed, VNC would seem like the right choice: a simple and open protocol.
Personally I'm interested in this and it'd be interesting to see it take off and benefit from all the usual mass-production efficiencies, as well as seing it develop more OS-like features (such as perhaps running user-supplied modules).
Sounds like the famous Chinese curse "may you live in interesting times". I don't want my computer to run yet another "interesting" operating system. I like it to bootstrap quickly and quietly into the OS of my choice.
Making web servers bulletproof isn't hard--they are one of the simplest network application you could imagine. Furthermore, these things would only run at boot time, which, if you run a decent OS, should be very, very rare. And even then, they mostly run behind firewalls.
Note that the 933MHz C3 is disproportionately faster because it (apparently) has a better memory system.
"Normal" home users, the kinds of people who might benefit from a GUI, probably don't want to talk to anything other than their main, mainstream OS. And power users and network administrators want the hardware to come with a system that can be scripted, extended, and remotely controlled. And almost everything that needs to be done with the BIOS-replacement should be done from the regular OS, which can leave little scripts in non-volatile areas for what the BIOS-replacement should do when it reboots (as opposed to putting those instructions into the user's brain).
Yes, the BIOS needs a serious overhaul, and, yes, it needs to change a bit in the direction of becoming a better OS. But it should become a better OS that normal users never have to talk to directly. It should become a 32bit/64bit OS that much more than previously accomplishes its magic behind the scenes. If it needs a GUI at all, the GUI should probably consist of a web server (so that the BIOS can be configured over the net) and a built-in, simple web browser, not some Microsoft-wannabe-lookalike.
I have an 800MHz C3 and a 600 MHz iMac (not too different from a 933MHz C3 vs. a 700MHz iBook): the C3 is indeed slower than the iMac in terms of raw CPU performance, but the GUI and applications actually run faster on the C3. Keep in mind that systems X11 were originally developed for machines like 8MHz 68k systems with a few megabytes of RAM. OSX, on the other hand, is really pushing the envelope in terms of system requirements.
Well, let's hope that those efforts get accelerated. The sooner KDE stops using X11 the better as far as I'm concerned.
VNC is not a replacement for X11. fbvncserver gives you a fixed 240x320 window on your desktop machine (and slowly and without desktop integration at that). X11 allows applications to open individual windows of arbitrary size on the desktop that behave just like any other application running on the desktop.
Oops--let's try the link again.
Since you are part of the KDE project, and since Qt/KDE/Zaurus/TrollTech supporters keep telling us how much better Qt/Embedded is than X11, and how cheap it is, and how efficient it is, and how everybody will gladly port to Qt, and all that, why isn't the KDE project getting rid of X11? Come on, do you lack the courage of your own convictions? Please tell us.
And I did NOT claim that Qt for the desktop had a licensing fee, so why are you shouting?
QT for the desktop only has a moderate one time developer fee, if you don't want to use GPL
If you consider $1550 or $2330 "moderate".
Qtopia is $195, Qt/Embedded, like their desktop products, is of the order of $2k per developer, plus runtime licenses. Since we are talking about Qt/Embedded for desktop apps, presumably, Troll Tech's current desktop pricing structure would apply.
You misunderstood; it was Microsoft that dropped the ball on providing applications for NT/PPC. For example, for Microsoft Office, they just told IBM: "you port it, we can't be bothered". For BackOffice, they told Motorola to port it (as if Motorola had the expertise to do this sort of thing). If Microsoft doesn't lead the way with porting their own applications, why should third party developers?
You've hit the nail on the head there. Microsoft have come to realize (or at least, believe) that they can't rely on any third parties. That's why they do operating systems, programming languages, end-user applications, back office servers, etc.
Of course, that's what they believe. That's because they are brash, insular people with a serious NIH attitude. They'll rather release some poor in-house hack quickly than figure out how to work with other companies or standards bodies. And because they are very, very big, they can get away with it: their broken prereleases may not be popular, but they are sufficient to damage the market for the established standards, and year by year, Microsoft takes over one market after another. Any other company would be bankrupt with such incompetent behavior, but given the Windows monopoly, that kind of incompetence is a successful business strategy for Microsoft.