The whole point of accelerator video cards is REDUCING the bottleneck between CPU/RAM/video.
Good graphics cards have their own processor, and they introduce a bottleneck between the CPU and graphics memory: sharing memory between processors is difficult, expensive, and raises caching issues. Video memory is particularly bad because a real-time process needs to read the stuff out and a real-time processor needs to render stuff from it. If, at the same time, you have the Pentium messing around in that memory, it gets really tricky.
The only reason why PC hardware supports that model is because of the PC software architecture and the expectations of PC programmers. In the long run, Graphics systems on the PC need to become more like X11, not the other way around. Writing into frame buffers is not an efficient long-term proposition.
[X] sure as hell going to have to implement a "I know I'm running as both client as server, let me optimize" mode.
It did that, oh, 15 years ago: shared memory and UNIX domain sockets. I have never seen any benchmark that indicates that anything more is needed.
It seamlessly allows local and remotely-running programs to work together on a display
As does Berlin, Berlin does even better than X.
Great! I'd love to do some benchmarking on its performance. It would be quite interesting if they managed to make a generic RPC system as efficient as a hand-crafted protocol. Too bad there is no installable package around.
Berlin does, too. But it strongly encourages to use the common facilities.
Those who don't know their history are condemned to relive it. For about a decade, X11 had one core toolkit on which most people built new widgets. It provided common behavior, common customizability, common layout, and other common functions. Then came Tcl/Tk, Fresco, and others.
I don't give Berlin even a couple of years before its "encouragement of common facilities" will be widely ignored. And if it backs up its encouragement with draconian enforcement, it will simply not be used. Sorry, that's the way software works.
I don't want every program to use a different widget set. I do want my programs to be able to support basic cut-and-paste.
Well, that's entirely your choice. If that's what you want, only use programs that have those features and don't mix-and-match toolkits. Among KDE, Gnome, Motif, Tcl/Tk, and even FLTK each individually (!) has more applications available for them than all of Berlin. The fact that you can mix-and-match and it mostly works is an added bonus that X11 gives you.
Besides, if Berlin ever were to catch on, you won't be able to prevent exactly the same thing happening on Berlin. You'd have X clients, Gtk+, Qt, FLTK, Java, and other apps all running on the same Berlin desktop, and they'd all have the same variety of looks, feels, and conventions as they do now. The only difference would be that Berlin would probably make the integration work less well than X11.
Having a general extension mechanism is a good thing. Needing to use it to provide basic functionality isn't such a good thing.
You are thinking desktop-only. X11 is used widely in industry and commercial applications, where antialiasing, scalable fonts, and other such features add unnecessary bloat. X servers and clients can be implemented in very little memory; if you mandate support for high-end desktop features on every client and server, X would be just a desktop windowing system.
I think Berlin has missed the boat on many fronts:
Even the few valid criticisms they had of X have been addressed: X now has antialiasing, transparency, and scalable fonts. (Yes, they are extensions, and that is quite proper: you want to be able to have low-footprint implementations of X without those features.)
Java/Swing is an almost literal implementation of the Berlin manifesto: instead of C++, it uses Java, instead of Fresco, it uses Swing, and in addition to CORBA, it also has RMI, SOAP, and a lot of other RPC mechanisms. It turns out that in practice, Java/Swing isn't usually used in the simplistic way envisioned for Berlin (although IBM has a remote AWT implementation). Once you bother with RMI, it's more efficient and simpler to run much more code on the display server. Unlike Berlin, Java/Swing also has a safe and efficient "display-side" extension language--Java itself.
Systems like Qt and Gtk+ now work directly on the framebuffer, and with VNC, the resulting system can even be accessed remotely.
(And, incidentally, Fresco is a nice toolkit, and it runs nicely on X11.)
I think Berlin has missed the boat. X11 has caught up, and better implementations of Berlin's ideas already exist. This is not the time anymore to loose another C++/CORBA thing on the world.
The frontiers in toolkits is elsewhere anyway. If you want to play around with a powerful, extensible toolkit, spend some time digging into Squeak. It's a research system and on the surface, it looks like a pretty unappealing and cumbersome system with a bunch of oddly colored windows. The documentation is so-so (take a look at the Wiki, it contains some tutorials). But Squeak and its toolkit, Morphic, are also extremely powerful, a window system in which everything is open to inspection and modification, in which everything can be made to interact with everything else, and in which there is a huge number of tools, browsers, and development tools. The whole thing can run on a plain frame buffer (it also runs fine under X11, Windows, or MacOS), and everything is built in Smalltalk.
I like the Palms--for keeping appointments, TODO-lists, and phone numbers. They are great little devices for that, well designed, simple, and efficient.
But I guess Palm discovered that forever computing in a market in which a typical device now costs $50 isn't such a good revenue model. So, they switched gears and are trying to compete with the niches filled by Newton or WindowsCE. But their platform wasn't designed for that, and it shows. Palms have a low resolution screen, no MMU, slow processor, and an operating system that is not particular convenient for writing custom applications. What you are paying for mostly with the m500/m505 isn't the hardware at all anymore, it's the "platform".
If you want to support Palm until they finally come out with something more powerful, or if you have a lot of money around, go ahead, buy their high end models. If I need to replace my Palm, at this point, it will be with the lowest end model (low-end Visor: $129, low-end m100: $149). It has more than enough power to keep my schedule and phone numbers. If I want something to run custom apps on, I want it to be more easily programmable than either the Palm or a WinCE machine, and that means having either Java or POSIX APIs with a MMU.
The simple economic fact is: You will put more energy into creating the hydrogen fuel than you can ever get out of it
If you are thinking of "burn oil, drive turbine, run generator, electrolyze water capture hydrogen", that's true. But that would be a lousy way to use hydrogen. The whole idea is that we want to get away from burning fossile fuel altogether because it's bad for us in many ways.
A process of "use bacteria to make hydrogen" or "use solar energy to make hydrogen" or "use biomass to make hydrogen" may or may not have a low efficiency, but it doesn't lose any energy at all relative to the alternatives since it captures solar energy that otherwise would have gone unused. And it has a lot of practical advantages, like using up CO2 and being less polluting.
Making hydrogen by electrolysis using electricity from oil, gas, or coal powered power plants is clearly not the way to go.
Since hydrogen can be stored and transported losslessly, you can generate it by solar energy in regions where solar energy is plentiful, cheap, and easy to use--like deserts. You can also generate it biologically.
X is just plain glacial on it, especially with KDE.
I have used X11 on machines that ran at 1/4 the speed and memory of your machine with no problems. The slowness you are seeing is in the toolkits. Also, the XFree86 implementation of X11 is probably not optimized for small machines (why should it be?), but since it is being ported to handhelds, that is getting fixed.
The effect of pushing agriculture into more and more marginal lands is not to save lives. Quite to the contrary: people will settle in these marginal lands and their populations will grow. But because this is agriculture pushed to its limits, the risk of crop failures is much higher than and good land that is farmed non-intensively. The net effect is that you will end up dealing with much larger populations at risk from famine than if you hadn't done this in the first place. And because such programs are so long term, you can't even make the argument that it saves lives of hungry people right now.
The only solution to famine is to limit our population. We can do that voluntarily, through family planning, or nature will do it for us through "natural disasters". And the more marginal the lands are we inhabit, the more like, the more devastating, and the more frequent those natural disasters are going to be.
It does matter where they got it from. Debian packages go through a rigorous testing procedure.
It seems to me that unless Progeny stealthily repackages modified packages under Debian names and version numbers, that issue just doesn't arise. If all the Debian dependencies are correct, a Debian package only depends on Debian packages, and so if someone reports a problem in a Debian package, it's a Debian problem. If someone asks you something about a Progeny package, don't respond or point out to them that people on the Debian list would know nothing about it.
And next time someone screws up in their VB or Perl mail forwarding script, re-mails a piece of spam to thousands of people in their (automatically collected) address book they get thrown in jail. Or, if the FBI doesn't like someone and can't get them on what they wanted, they'll claim that their submission to a mailing list was actually spam ("Didn't it get sent to thousands of people?", "Didn't it refer to a commercial product?"). Who knows--maybe someone would manage to construe applease by, or on behalf of, Randy Schwartz "spam".
I think spam should be illegal: that gives ISPs and others a good justification for filtering it out. But once you start talking harsh penalties, you are giving some pretty clueless people with a distrust of anything digital some pretty strong weapons, weapons that can easily be used against you. Jail time for sending E-mail? Give me a break.
My worry is that they'll take advantage of Debian the community. Perhaps by shirking on tech support and reffering people to regular Debian support channels,
If they are asking about a Debian package, why does it matter how they got it? If they are asking a Progeny-specific question, asking it on a Debian list would seem to be pointless anyway.
And how is this different anyway from what RedHat or Debian are doing? Both RedHat and Debian increase the distribution of free software packages to a much larger and less sophisticated audience than if the package was just a source.tar.gz. Should free software authors start saying "don't ask me about it if you installed it from a Linux distribution; I will only answer questions about it if you installed it from the source?"
Can you be more specific about in what way it is a variant?
If it's the kind of variant that cannot update from Debian sources, then it's the kind of variant I'm not interested in.
OTOH, if it's the kind of variant that has a better installer and a bunch of new packages containing better sys admin tools, but that can be updated for regular Debian sources, then it's the kind of variant I'm very interested in, since installation and system administration are real shortcomings of "the real Debian".
In practice, you need something that ties a date and publication together, involves a third party, and is comprehensible to legal types. Something that libraries buy and archive is a pretty safe bet: a scientific journal or a corporate disclosure publication.
Merely using the code on a web site clearly isn't publishing. Putting the source code on a web site might be publishing, but proving an actual date in court might be hard. OTOH, having your code notarized would establish a date but not constitute publication. Having your code end up on an open source CD-ROM might work, but it might be too technical for the legal system (or a jury) to believe that it actually constitutes "publication".
Prior art requires a published document. If you've been doing something since the Middle Ages, but you've never published it, it's not prior art
Indeed, "we did this in 1997" is not prior art (see my other message).
However, your statement isn't quite right either. If something has been done "since the middle ages", it's a standard part of the profession and it should be obvious to someone skilled in the art and hence not patentable.
There are lots of patents recently that try to patent common, well-known practice that has never been written down. This doesn't just come up with software but also with, say, traditional medicine. Those patents are hard to get invalidated in practice, but they probably are invalid even under current patent law if the facts can be established; and to the degree that they can't be invalidated, it's a problem with the legal process.
Deploying a system that does something may not constitute prior art; you often need to publish a description of what you are doing. So, if Slashdot used on-line polling before this patent was filed, but it wasn't actually written up and disclosed, it may not count.
The assumption behind patents, after all, is that they are a non-obvious invention. While, in some cases (paperclip?) the invention may be obvious from the product, in many cases it is not. Using an invention without disclosing it is exactly what the patent system is supposed to avoid.
Of course, in this case, as in many other cases, it's silly. But it's important to keep this in mind even when trying to strike down silly patents. I think the argument would have to be more along the lines of "lots of people did it, nobody bothered even filing a patent, so it really was considered obvious by the community". But that seems to be legally a much harder argument to make.
People have known about these vulnerabilities for a long time. Why haven't they gotten fixed? Because they haven't been much of a problem yet--there are a lot of bugs and problems that are easier to exploit.
With this publicity, two things may happen. First, more TCP implementors may get embarrassed and address this issue in their code. Second, crackers may get alerted to it and write tools and exploit it more. Are we better off altogether? I dunno. What I do know is that there are people who win no matter what: people seeking publicity by announcing yet another well-known security hole.
There's is no requirement in patent law to actively defend your patent (like there is in trademark law).
Indeed. But wouldn't it be great if there actually was a requirement to enforce your patent within, say, a year if you were informed of an infringement? Companies who treat huge, vague patent portfolios as bargaining chips wouldn't be able to do so easily, while small, productive companies that develop specific products based on their patents would.
I like my PalmPilot. It works well for what it is intended to do.
But I think the prices that Palm and Palm licensees are charging are out of proportion to the software and hardware. PalmOS is a pretty messy and limited OS, and the company has gotten its return on investment many times over. And the screens and processors on most PalmPilots devices are laughable--pay $400 for some of the Palm devices with a 33MHz 68k with a 160x160 screen? At least the Clie has 320x320, but how well is software actually going to support that?
I think Palm computing is turning into the equivalent of Microsoft: they are falling way behind technologically, but they have a proprietary platform that a lot of people have invested a lot of time and money in and they are squeezing it for every dollar it's worth.
I hope my Palm Pilot will last until PocketLinux becomes a feasible alternative--I would feel silly paying that kind of money for a technologically outdated platform. If I need to buy another one, the lowest end Palm will be just fine: PalmOS doesn't know what to do with a really powerful machine as far as I'm concerned.
Maybe it's time that software slimmed down a bit and that people picked better tools to build their software. Too much money allows people to brute-force projects like Mozilla, Eazel, and Ximian even if their tools (C, C++) aren't very good. Maybe if resources become more limited, people will start paying more attention to tools and basic principles before they go off programming.
I think the right business model for free software is consulting and contracting, not startups.
Consultants and contractors are directly paid to do a good job. They have a reputation to protect in their line of work. They are professionals that are in it for the long run because it's their own career. Because they are in it for the long run, they have an interest in doing the right thing, cleaning things up, and maintaining things.
Startups are a kind of hit-and-run business: investors want to get high returns on investment by any means, and if that can be done over a six months by hyping and without delivering quality, that's just fine with them. Much of the technologies that startups are based on (and busily patenting) wasn't even financed by the investors but by research grants (unfair as it seems, it may still be a good deal for society, since a lot of that comes back in taxes if the company succeeds).
So, no, I don't see much of a future in open source software startup companies. After those companies have extracted the excess value that free software has, they have nowhere to go, and I don't think in a startup climate they create the right kinds of long-term foundations for themselves to prosper. But I see a bright future in open source software consulting, contracting, and teaching.
Don't cry for the people at Eazel or Ximian or whatever, though. They are bright, they knew what they were getting into. If their companies fail, they didn't lose, they just didn't win big. They'll get by just fine as consultants or back in the fold at a big company.
Slashdot Mirror
Good graphics cards have their own processor, and they introduce a bottleneck between the CPU and graphics memory: sharing memory between processors is difficult, expensive, and raises caching issues. Video memory is particularly bad because a real-time process needs to read the stuff out and a real-time processor needs to render stuff from it. If, at the same time, you have the Pentium messing around in that memory, it gets really tricky.
The only reason why PC hardware supports that model is because of the PC software architecture and the expectations of PC programmers. In the long run, Graphics systems on the PC need to become more like X11, not the other way around. Writing into frame buffers is not an efficient long-term proposition.
[X] sure as hell going to have to implement a "I know I'm running as both client as server, let me optimize" mode.
It did that, oh, 15 years ago: shared memory and UNIX domain sockets. I have never seen any benchmark that indicates that anything more is needed.
Great! I'd love to do some benchmarking on its performance. It would be quite interesting if they managed to make a generic RPC system as efficient as a hand-crafted protocol. Too bad there is no installable package around.
Those who don't know their history are condemned to relive it. For about a decade, X11 had one core toolkit on which most people built new widgets. It provided common behavior, common customizability, common layout, and other common functions. Then came Tcl/Tk, Fresco, and others.
I don't give Berlin even a couple of years before its "encouragement of common facilities" will be widely ignored. And if it backs up its encouragement with draconian enforcement, it will simply not be used. Sorry, that's the way software works.
Well, that's entirely your choice. If that's what you want, only use programs that have those features and don't mix-and-match toolkits. Among KDE, Gnome, Motif, Tcl/Tk, and even FLTK each individually (!) has more applications available for them than all of Berlin. The fact that you can mix-and-match and it mostly works is an added bonus that X11 gives you.
Besides, if Berlin ever were to catch on, you won't be able to prevent exactly the same thing happening on Berlin. You'd have X clients, Gtk+, Qt, FLTK, Java, and other apps all running on the same Berlin desktop, and they'd all have the same variety of looks, feels, and conventions as they do now. The only difference would be that Berlin would probably make the integration work less well than X11.
Having a general extension mechanism is a good thing. Needing to use it to provide basic functionality isn't such a good thing.
You are thinking desktop-only. X11 is used widely in industry and commercial applications, where antialiasing, scalable fonts, and other such features add unnecessary bloat. X servers and clients can be implemented in very little memory; if you mandate support for high-end desktop features on every client and server, X would be just a desktop windowing system.
I think Berlin has missed the boat. X11 has caught up, and better implementations of Berlin's ideas already exist. This is not the time anymore to loose another C++/CORBA thing on the world.
The frontiers in toolkits is elsewhere anyway. If you want to play around with a powerful, extensible toolkit, spend some time digging into Squeak. It's a research system and on the surface, it looks like a pretty unappealing and cumbersome system with a bunch of oddly colored windows. The documentation is so-so (take a look at the Wiki, it contains some tutorials). But Squeak and its toolkit, Morphic, are also extremely powerful, a window system in which everything is open to inspection and modification, in which everything can be made to interact with everything else, and in which there is a huge number of tools, browsers, and development tools. The whole thing can run on a plain frame buffer (it also runs fine under X11, Windows, or MacOS), and everything is built in Smalltalk.
But I guess Palm discovered that forever computing in a market in which a typical device now costs $50 isn't such a good revenue model. So, they switched gears and are trying to compete with the niches filled by Newton or WindowsCE. But their platform wasn't designed for that, and it shows. Palms have a low resolution screen, no MMU, slow processor, and an operating system that is not particular convenient for writing custom applications. What you are paying for mostly with the m500/m505 isn't the hardware at all anymore, it's the "platform".
If you want to support Palm until they finally come out with something more powerful, or if you have a lot of money around, go ahead, buy their high end models. If I need to replace my Palm, at this point, it will be with the lowest end model (low-end Visor: $129, low-end m100: $149). It has more than enough power to keep my schedule and phone numbers. If I want something to run custom apps on, I want it to be more easily programmable than either the Palm or a WinCE machine, and that means having either Java or POSIX APIs with a MMU.
No, not at all. There are a number of X applications that don't use any toolkit. And there are a number of lightweight toolkits out there.
for i in *; do echo $i; done
Seems pretty much as short.
find -name \*.dvi | xargs gzip
If you are thinking of "burn oil, drive turbine, run generator, electrolyze water capture hydrogen", that's true. But that would be a lousy way to use hydrogen. The whole idea is that we want to get away from burning fossile fuel altogether because it's bad for us in many ways.
A process of "use bacteria to make hydrogen" or "use solar energy to make hydrogen" or "use biomass to make hydrogen" may or may not have a low efficiency, but it doesn't lose any energy at all relative to the alternatives since it captures solar energy that otherwise would have gone unused. And it has a lot of practical advantages, like using up CO2 and being less polluting.
Since hydrogen can be stored and transported losslessly, you can generate it by solar energy in regions where solar energy is plentiful, cheap, and easy to use--like deserts. You can also generate it biologically.
Yes, but that's already accounted for in the price of oil.
I have used X11 on machines that ran at 1/4 the speed and memory of your machine with no problems. The slowness you are seeing is in the toolkits. Also, the XFree86 implementation of X11 is probably not optimized for small machines (why should it be?), but since it is being ported to handhelds, that is getting fixed.
The only solution to famine is to limit our population. We can do that voluntarily, through family planning, or nature will do it for us through "natural disasters". And the more marginal the lands are we inhabit, the more like, the more devastating, and the more frequent those natural disasters are going to be.
It seems to me that unless Progeny stealthily repackages modified packages under Debian names and version numbers, that issue just doesn't arise. If all the Debian dependencies are correct, a Debian package only depends on Debian packages, and so if someone reports a problem in a Debian package, it's a Debian problem. If someone asks you something about a Progeny package, don't respond or point out to them that people on the Debian list would know nothing about it.
I think spam should be illegal: that gives ISPs and others a good justification for filtering it out. But once you start talking harsh penalties, you are giving some pretty clueless people with a distrust of anything digital some pretty strong weapons, weapons that can easily be used against you. Jail time for sending E-mail? Give me a break.
If they are asking about a Debian package, why does it matter how they got it? If they are asking a Progeny-specific question, asking it on a Debian list would seem to be pointless anyway.
And how is this different anyway from what RedHat or Debian are doing? Both RedHat and Debian increase the distribution of free software packages to a much larger and less sophisticated audience than if the package was just a source.tar.gz. Should free software authors start saying "don't ask me about it if you installed it from a Linux distribution; I will only answer questions about it if you installed it from the source?"
If it's the kind of variant that cannot update from Debian sources, then it's the kind of variant I'm not interested in.
OTOH, if it's the kind of variant that has a better installer and a bunch of new packages containing better sys admin tools, but that can be updated for regular Debian sources, then it's the kind of variant I'm very interested in, since installation and system administration are real shortcomings of "the real Debian".
Merely using the code on a web site clearly isn't publishing. Putting the source code on a web site might be publishing, but proving an actual date in court might be hard. OTOH, having your code notarized would establish a date but not constitute publication. Having your code end up on an open source CD-ROM might work, but it might be too technical for the legal system (or a jury) to believe that it actually constitutes "publication".
However, your statement isn't quite right either. If something has been done "since the middle ages", it's a standard part of the profession and it should be obvious to someone skilled in the art and hence not patentable.
There are lots of patents recently that try to patent common, well-known practice that has never been written down. This doesn't just come up with software but also with, say, traditional medicine. Those patents are hard to get invalidated in practice, but they probably are invalid even under current patent law if the facts can be established; and to the degree that they can't be invalidated, it's a problem with the legal process.
The assumption behind patents, after all, is that they are a non-obvious invention. While, in some cases (paperclip?) the invention may be obvious from the product, in many cases it is not. Using an invention without disclosing it is exactly what the patent system is supposed to avoid. Of course, in this case, as in many other cases, it's silly. But it's important to keep this in mind even when trying to strike down silly patents. I think the argument would have to be more along the lines of "lots of people did it, nobody bothered even filing a patent, so it really was considered obvious by the community". But that seems to be legally a much harder argument to make.
With this publicity, two things may happen. First, more TCP implementors may get embarrassed and address this issue in their code. Second, crackers may get alerted to it and write tools and exploit it more. Are we better off altogether? I dunno. What I do know is that there are people who win no matter what: people seeking publicity by announcing yet another well-known security hole.
Indeed. But wouldn't it be great if there actually was a requirement to enforce your patent within, say, a year if you were informed of an infringement? Companies who treat huge, vague patent portfolios as bargaining chips wouldn't be able to do so easily, while small, productive companies that develop specific products based on their patents would.
But I think the prices that Palm and Palm licensees are charging are out of proportion to the software and hardware. PalmOS is a pretty messy and limited OS, and the company has gotten its return on investment many times over. And the screens and processors on most PalmPilots devices are laughable--pay $400 for some of the Palm devices with a 33MHz 68k with a 160x160 screen? At least the Clie has 320x320, but how well is software actually going to support that?
I think Palm computing is turning into the equivalent of Microsoft: they are falling way behind technologically, but they have a proprietary platform that a lot of people have invested a lot of time and money in and they are squeezing it for every dollar it's worth.
I hope my Palm Pilot will last until PocketLinux becomes a feasible alternative--I would feel silly paying that kind of money for a technologically outdated platform. If I need to buy another one, the lowest end Palm will be just fine: PalmOS doesn't know what to do with a really powerful machine as far as I'm concerned.
Maybe it's time that software slimmed down a bit and that people picked better tools to build their software. Too much money allows people to brute-force projects like Mozilla, Eazel, and Ximian even if their tools (C, C++) aren't very good. Maybe if resources become more limited, people will start paying more attention to tools and basic principles before they go off programming.
Consultants and contractors are directly paid to do a good job. They have a reputation to protect in their line of work. They are professionals that are in it for the long run because it's their own career. Because they are in it for the long run, they have an interest in doing the right thing, cleaning things up, and maintaining things.
Startups are a kind of hit-and-run business: investors want to get high returns on investment by any means, and if that can be done over a six months by hyping and without delivering quality, that's just fine with them. Much of the technologies that startups are based on (and busily patenting) wasn't even financed by the investors but by research grants (unfair as it seems, it may still be a good deal for society, since a lot of that comes back in taxes if the company succeeds).
So, no, I don't see much of a future in open source software startup companies. After those companies have extracted the excess value that free software has, they have nowhere to go, and I don't think in a startup climate they create the right kinds of long-term foundations for themselves to prosper. But I see a bright future in open source software consulting, contracting, and teaching.
Don't cry for the people at Eazel or Ximian or whatever, though. They are bright, they knew what they were getting into. If their companies fail, they didn't lose, they just didn't win big. They'll get by just fine as consultants or back in the fold at a big company.