But, referring to doing this on native Windows code is not a good idea
at all. Remember the EULA, simply having the Windows code on your disk constitutes
acceptance of the EULA and reverse engineering by assembly dumps is explicitly
defined as a violation of the EULA. In other words you are setting yourself
in a position for major legal problems.
Don't believe everything you read. Just because Bill Gates writes into
the EULA that you'll work as his towel boy if you open the box doesn't mean
you are actually legally obligated to.
The only legitimate way to reverse engineer software is the method used
by the Samba team. You must look at the input and look at the output and then
determine your OWN method of achieving the same result.
Sorry, but you don't know what you are talking about. That is not "the
only legitimate way".
Thus ANYTHING that you produce afterwards the even vaguely resembles the operation
of the original software will place you in a losing position, legally
Oh, please, stop the hysteria. These things need to judged on a case-by-case
basis. I frankly doubt that reverse engineering a trojan/virus will
get you into hot water with Microsoft's EULA.
SVG is a better standard than Flash because it's text based and much easier to manipulate. However, Flash has the authoring tools that web designers use and it ships with almost every browser, whether you want it or not.
The lack of authoring tools for SVG may actually turn out to be an advantage. People doing Flash seem to be mostly using it for things that are very annoying to users, and they are often not doing it very well (that flashing, blinking web interface doesn't resize, for example). SVG may turn out to be a better and more acceptable format for vector graphics than Flash precisely because the people who shouldn't use it don't know how to anyway (of course, that blessed state will not last long--if it catches on, Macromedia will output SVG, too).
But until SVG becomes supported out of the box, with no plugins, by IE and Mozilla, it won't catch on much. Microsoft may support SVG in IE just to spite Macromedia--let's hope so. But it is incomprehensible to me why Mozilla has been so slow to offer SVG support: it already has all the XML parsing and graphics primitives built in--why is SVG support so difficult?
I don't see why this kind of thing should cause revulsion. Ants are extremely useful and interesting and they are usually harmless. If there is anything disturbing about this it's that such useful critters needed to be destroyed.
If a new product or technology wants to replace an existing (and dominant)
incumbent, then it has to make the transition as easy as possible or present
an extremely compelling reason why it shouldn't. [...] While you may
believe that your product is "worth it", unless your potential customers
believe it as well, they aren't going to switch.
My point is: I don't want you to convince you to switch, nor do I want to
hack up my software to make it easier for you to switch. What I do
want you and anybody else to do is not to be guided by misconceptions when
choosing software or to influence Linux software development to become more
of a Windows clone.
It is perfectly legitimate to say "I'm going to stay with Photoshop because
I know it and because it works for me". It is, however, irrational
and counterproductive to approach the issue by saying "Linux imaging software
is no good because it doesn't work like Photoshop".
The problem with free software is that nobody is interested in convincing
other people to switch. The developers of free software are doing so predominantly
for their own benefit ("I want to make a tool easier for me to use"), and
while that ability is a major plus for some people, it shouldn't be any surprise
that "regular" people aren't impressed with the results. After all, they
aren't catered to, as they are with "commercial" software.
I don't see this as a problem, I see it as a strength. I don't want
software design to be driven by marketing considerations. And I definitely
don't want open source software to behave like Windows software--if I wanted
to use Windows, I would be using it.
You'll probably see pretty cheap (my guess is $20-$50) Bluetooth serial dongles
coming out in 2003. And, of course, you can already get unpackaged Bluetooth
modules from Ericsson that effectively have a Bluetooth connector. And
you'll probably see more PICs with Bluetooth capabilities. Those are likely
to be a more convenient and robust solution than special-purpose 900MHz serial
hacks. They will also allow you to talk to the serial devices from
any Bluetooth dongle, not just a proprietary one.
You can, of course, already get Bluetooth USB dongles for around $30. Those
are really great little pieces of hardware, and you can stick them on just
about any computer that needs to communicate wirelessly.
I seriously doubt that the boards that GENRIP works with are "ultra low-cost".
Their web site doesn't have any prices that I could see, and these kinds
of boards tend to be costly.
I think Windows is a piece of junk as an operating system. But there is software that only runs on Windows, so I have a low-end Windows laptop sitting around (I can also dual-boot my Linux machine). One of the best applications (relatively speaking) on Windows is IE--it's a decent web browser, and since the Windows laptop isn't good for much else, I use it for web browsing.
No matter how fast they make the drivers, no matter how much they optimize
it - a client-server based desktop environment is ALWAYS going to be slower
than a non-c/s solution.
First of all, there are almost no "non-c/s" window systems left. Windows
and Mac OS X are both "client server" windowing systems as well--all multiprocess
windowing systems need a server to handle interaction among multiple applications.
And, in fact, neither Windows nor Mac OS X applications draw to the
screen directly either: in the case of Windows, they call a GDI server in
the kernel, and in the case of Mac OS X, they generate PDF that gets sent
to a server. Last I did benchmarks, X11 beat both Windows and the Mac
OS X GUI handily in terms of performance on comparable hardware (although
there certainly are going to be some graphics cards for which Windows outperforms
X11, depending on driver quality).
Second, it just isn't true that "client server" is always slower than a "non
client server" solution. As just one simple example, if you run X11
on a dual processor machine, you automatically get parallelism, where the
application and the display code run on separate processors.
In addition, modern window systems can't help but be client/server: graphics
chips have their own processors; applications effectively draw by sending
requests to those graphics chips. Putting pixels directly into the framebuffer
is very slow.
Finally, if anybody felt that direct rendering was important for writing a
fast GUI toolkit for X11, X11 supports it: you can use DRI and fiddle around
with on-screen bits as much as you like. Toolkits don't do that because it
just doesn't make sense for a general purpose toolkit.
X continues to feel just a bit sluggardly on all my systems, even with the
latest, fanciest drivers from whoever.
Well, the most likely cause of that is not X11 but your chosen desktop environment.
For example, if you are running Gnome or KDE, that's the source of your
performance problems. Those environments (and their toolkits) impose enormous
and unnecessary overhead. They don't use a lot of the rendering facilities
available natively in X11 and do a lot of rendering in software and then
blit it to the screen. Of course, most people aren't bothered by that
because even with their overhead, Gnome and KDE are fast enough on modern
hardware.
The second biggest problem I have with Linux is stability. Linux itself
is a rock, but I have not used a single X app that hasn't crashed at least
once. It's a dismal record.
Well, you seem to be using the wrong applications, then. There are
buggy GUI apps on any platform. On X11, at least you are guaranteed
that a buggy GUI app can't take down the whole window system. And because
X11 is a protocol rather than an API, you can eliminate the most likely cause
of crashes from your programs entirely: C-based APIs. Languages like
Lisp, Java, and ML have bindings to X11 that are entirely free of C code.
X11 is far more stable as a window system than anything else I have seen,
and it's by far the best architecture around for building stable GUI apps
because it separates the display code from the client code so cleanly (DisplayPDF
and DisplayPostscript come close). The fact that there are some big
and vocal projects producing buggy clients for X11 isn't X11's fault. Judging
the stability of X11 by the stability of some free clients is like judging
the stability of Windows by the stability of shareware apps you download.
I don't see how it's ever going to do it relying on X, and I don't see the
desktop environments coming anywhere near more polished corporate-funded alternative
X11 is one of the biggest strengths of Linux. If it didn't exist, it
would have to be invented.
And X11 is widely used in corporations and businesses, in particular in mission-critical
applications like banking.
Ditch X and come up with a really solid desktop environment that doesn't
require it, and I'll be back in a heartbeat.
We can't make everybody happy all of the time. So, have fun with Windows.
You won't be missed.
What keeps you using Photoshop is the same that keeps other people using
Windows: you are used to certain tools, they get your job done, and you don't
want to spend the time learning something new. There is nothing wrong
with that. But that's your problem, not a problem with Linux or Linux
applications.
Having been in digital imaging for 20 years, I assure you that Linux and
UNIX are an excellent platform for digital imaging. In fact, once you
learn the tools, it's a lot better than Photoshop or Windows in my opinion.
I have used Photoshop, and you couldn't pay me to switch to it: it's
just the usual, bloated, monolithic software style that is so common on Windows.
IEEE seems to be good at sharing infromation, with a few small problems.See
their terms
and conditions [ieee.org] for yourself.
That link points to their web site copyright, and the other link you give
is a "web publishing howto" with no relationship to their scientific and engineering
publications.
If you want to know what their scientific publishing policies are, take a
look at their copyright
transfer form: like other scientific publishers, they require you to transfer
your copyright to them and severely limit your own rights to reusing the
content.
There are some publications (mostly peer-reviewed on-line journals) that
are trying to break the stranglehold of such agreements. They don't
require copyright transfer, but just ask you for a license that lets them
republish your work to which you retain the copyright.
Peer review is part of active research and should be thought of as part
of any research position. It keeps you up to date and sharpens your brain
It is and it does. But since publishers get the peer review for free,
by far the most valuable part of scientific publishing, they should then not
charge huge amounts of money for the publications themselves.
In particular, it is incomprehensible why a non-profit organization like
the IEEE should charge anything significant for on-line access to their digital
library, whose contents were created, reviewed, and edited almost entirely
by volunteers, and whose creation is more than paid for already by the high
charges for the print publications.
In fact, if you retained the copyright, competition would easily take care
of price gouging in scientific publishing, since publishers that overcharge
would face competition from publishers that don't and end up reprinting the
same works.
The burden of clerical work is a different and unrelated issue. You should
have an expert at digital publishing who can take your plain text, raw data
and notes on equations, and turn them into decent looking papers on the web
and on paper trough Apache, LaTex, DX and any other useful system. Secrataries
should be up to this task. Anything else is wasteful of real research time.
Secretaries? Maybe there are still a few plush places that have those,
but no real-world place has those anymore. Most researchers have administrative
assistants, and they don't do typing or type setting.
In any case, that's besides the point. The point is that publishers
often don't even do the type setting and layout anymore themselves either,
which again raises the question of what they actually are charging all that
money for.
Paramount (or whoever) creates Spiderman, they own it both legally and ethically, you copy Spiderman, Paramount has a legitimate complaint.
The government pays Dr. Smith to write a scientific article. Dr. Smith gives the article to a scientific publisher and receives no compensation. That's the same publisher that Dr. Smith also puts in many hours in unpaid editorial work. The government puts Dr. Smith's paper on the web. The publisher, who contributed nothing to either the creation or the editing of the article, complains about this. They have neither a legal leg to stand on (the government refuses to sign over the copyright--they are big enough to be accomodated), nor do they have an ethical leg to stand on (the publishers contributed nothing to the content).
It gets even worse for educational or private researcher. Prof. Johnson writes a scientific article and needs to get it published in order to get tenure. The IEEE or Springer or whoever says: we only publish this article if you sign away all your rights to it and then some. Prof. Johnson also needs an editorial board position on his resume to get tenure, so he puts in many more unpaid hours doing editing, reviewing, and clerical work for the publisher.
Scientific publishing is a racket similar to the mafia. The only difference is that scientific publishers don't kill you with a bullet; it's just if you don't cooperate and put in hundreds of thousands of dollars worth of specialized, unpaid labor, your scientific career is over.
So, there you have your answer. For the DivX, the legal and ethical copyright holder complains. For the scientific articles, companies with no legal or ethical basis flex their political muscle and get their way. It's pretty disgusting.
From the description, it sounds like PubScience was not "stealing" articles. Whether that's because they didn't offer the full text of certain materials or because copyright laws apply differently to the government is another question.
Just like we're not allowed to sell things for less than they cost, the DOE should not be allowed to do this.
Quite to the contrary. It is actually the primary function of governments to give us services at a price that would be unaffordable for the people who need them if they were made available by the market. You or I can't afford to buy police protection, or highways, or a military on the open market, but we need those services, and we elect our government to provide them to us outside the usual market mechanisms.
When it comes to scientific literature, society has a compelling interest in divorcing its availability from market sources. It should not cost $15 or $40 to get a research article. If it does, publishers are either price gouging, or they simple can't provide the service at the price that researchers can pay. Either way, the government has a strong interest to step in.
What is particularly galling about this is that the publishers actually pay nothing for the content: the content is created by researchers often paid for by the government or industry, and all the reviewing and editing is also done for free by volunteers. Authors even typeset the stuff themselves these days. If anybody is "stealing", it's the scientific publishers.
"So, come on, be specific and concrete: where exactly is the Qt/Embedded architecture supposed to save memory compared to the X11 architecture? Tell us."
Because it writes directly to the framebuffer, instead of passing things around to someone else and asking them to write it.
Ummm--how exactly does "asking someone else" use more memory? What do you think uses that memory?
Client/Server always involves more overhead
Quite to the contrary. For example, 100 PCs running Windows require a lot more memory and CPU power to get the same work done as single server with 100 terminals.
It's similar with X11. Because it carefully separates concerns, X11 clients can be incredibly simple and lightweight (of course, Qt/X11 and Gtk+/X11 are dogs, but that's a different story). Some X11 clients run on 8bit micros and take as little as a few hundred bytes of code and data combined. Having all the graphics happen in a single process, like in X11, also makes things much smaller and simpler on the server side.
On the other hand, mapping the frame buffer and putting graphics code in every client, like Qt/Embedded does, involves a lot of overhead, duplicated data structures, and duplicated code.
Abstracting things out into different layers always adds more overhead.
Premature optimization is the root of most performance problems and bugs, and Qt/Embedded is another example of that. A good architecture beats a hack almost always.
Say you want to write an email, you would tap the email app, tap the to: field and a list of previous address used would pop up. You would select one, and then start scribbling away.
Yes, that's how Linux e-mail applications work. What's your point?
Handwriting recognition is the killer feature here and Microsoft has done tons of research on this. Check out the Microsoft Research website.
Microsoft has hired a bunch of good people over the years, but there is nothing special about Microsoft's handwriting recognition efforts or technology: lots of people understand how to do something that's pretty close to state-of-the-art, and nobody (not Microsoft, not anybody else) has implemented a completely satisfactory system.
Handwriting recognition used to be a hard engineering problem on machines like the Newton, which were slow and had limited amounts of memory, but that's not a big deal anymore with modern tablets.
"tappable" is a word, formed using standard rules from "tap" and "-able". It's in some use: try searching for "tappable" and "tappable keyboard" on Google. Dictionaries don't usually list derived words like this whose meaning is obvious to most native speakers.
Did I just miss it in the article? I can't find any link to the company, nor any reference to the company or product anywhere else on the web. Does anybody know more?
$800 really is a good deal on a pen-based computer, and this thing should have lots of applications, if not in the consumer area, then in vertical markets.
The Tablet PC is cool because of all the software that handles inputing with an stylus and integrating that with the rest of applications.
There is plenty of Linux software designed to run with pen input--after all, Linux has been used on handhelds for a number of years.
Most mouse based applications work naturally with a pen anyway. Web browsing, e-book reading, marking up text, drawing, and things like that work like a charm with standard Linux applications on a Linux-based tablet. And even with no handwriting recognition, an on-screen keyboard makes entering text and data quite easy and quick and, again, requires no application changes (given the modular X11 architecture). And fully integrated handwriting and gesture recognition also already exists for X11.
Maybe it was a lot of work to integrate pen input into Windows, but Linux and X11 are modular and mature enough that this is not an issue.
I don't see why not. There is already handwriting recognition for Linux handhelds (see handhelds.org). Squeak is an open source Smalltalk environment that runs on Linux and is intended to be usable with pen input. The most high-performance handwriting input engines are the ones that define a special alphabet, and those are also easier to implement than unconstrained handwriting. And on-screen tappable keyboards are actually pretty efficient as well. Even if you try to implement mostly unconstrained handwriting recognition, in practice, handwriting recognition is generally simpler than speech recognition, and there are open source speech recognizers (you can even adapt a speech recognizer to handwriting recognition--a lot of the software is very similar). And X11 already has support for different kinds of input methods, so the software architecture is in place as well.
And many functions of pen computers don't require handwriting recognition at all (ink notes, browsing, e-books, etc.)--just getting rid of that bulky keyboard alone when it's not needed would be worth the pen computer.
Lets suppose we decided you were right, and instead of using QTEmbedded on top of the linux framebuffer, we used regular QT and stuck an X11 server inbetween QT and the linux frame buffer. You are saying this X11 solution is a ligherweight solution than QT straight on the framebuffer?
Why shouldn't it be? Why should "sticking a process inbetween" use a lot more memory? Even all things being equal, except for a process table entry and a small IPC buffer, what memory do you believe a client/server approach requires compared to a frame buffer library?
And, in fact, QPE requires multiple processes and inter-process communication just like X11--that's because, just like X11, it runs on a multitasking OS and supports multiple clients, and the clients need to coordinate window management. The only difference is that in Qt/Embedded each application writes to the frame buffer directly for low-level drawing, while in X11, drawing operations are sent as IPC messages to the window server by default (with direct rendering an option). Basically, Qt/Embedded is just like X11 using DRI for rendering.
So, come on, be specific and concrete: where exactly is the Qt/Embedded architecture supposed to save memory compared to the X11 architecture? Tell us.
Overheard in the executive suite: "Well, let's see, if we pay $50m to each of us as bonuses and $20m to the investors, there is just no profit left. Strange how that works out, isn't it."
I did read your message carefully, specifically this point [...] To
my reading this implies that Qtopia contains flab from KDE. However, there
is no KDE "flab" in Qtopia.
Well, your reading is wrong. The "flab" I was referring to was the "flab"
that was "cut out", not the bloat that remains in QPE and Qt/Embedded after
all the "flab" was removed.
The QPE process alone is using 1.7Mb, not 6.7Mb. The rest is shared
libraries.
No. The 6.7Mbytes is the resident set size, i.e., the amount of
RAM that the QPE process needs to run. Yes, that includes portions
of shared libraries that the process needs to run (it also does on the Agenda
numbers), so let's say for the sake of argument that all other processes
combined use no memory whatsoever--that way we can be certain that we count
not a single byte twice. Then, the QPE process uses more memory than
the entire Agenda software environment uses, including X11 server, toolkit,
input methods, task bar, wireless LAN monitors, desktop synchronization,
etc. The Agenda only has 8Mbytes. And the numbers are roughly
the same if you run X11 on the Zaurus.
No matter how you apportion it, QPE is worse than X11 in terms of resource
usage. Face the facts.
If you want to say which is smaller you either need to compare the agenda
X11 + window manager with a stripped down QPE with no application launcher,
no task bar, no input methods, no wireless lan monitors, no desktop syncronisation
code etc etc etc.
I stated what I compared.
Does comparing XFree86 + twm + xterm with KDE make much sense? twm is 50
times smaller than KDE, twm must be better right?
Well, it is the Qt/Embedded proponents that claim that smaller is better,
not me. I merely point out that Qt/Embedded happens to be pretty heavyweight,
in particular compared to X11.
As for speed, i have seen no benchmarks myself, and you have provided none,
so in the meantime i'll presume such claims as "X11 is faster than QT" are
pure speculation
They are not "speculation", they are observation, as I indicated. I
have a Zaurus (as well as several other handhelds), and I have run the window
systems on identical hardware. It is also my observationthat
QPE or Qt/Embedded is susceptible to focus problems that require a reboot--not
good on handhelds.
Fair enough, but i suspect Sharp doesn't see that as much of a market,
the average PDA user doesn't know or care what X11 is.
Based on actually using it, I think the "average PDA user" would be a fool
to buy a Zaurus. A Palm is a much better handheld for day-to-day PDA usage:
it's smaller, it's lighter, it's better supported, it's cheaper, and it interfaces
better with Windows, OS X, and (ironically) Linux. The only area where Linux-based
PDAs can shine is for software development, but the Zaurus GUI is incompatible
with all Linux and UNIX toolkits and desktop environments except one. In
my opinion, the Zaurus has no future, at least in the US market: it's not
a good consumer device, and it's not a good device for hackers.
In any case, all I said is that I won't be ugprading my SL-5500, and
I gave the reasons why. You are free to waste your money in whatever way you
like.
Well, given that the QPE process alone is several times as large as X11, the window manager, and the terminal application combined, the question really isn't whether Qt/Embedded is worse in terms of resource usage than X11, but only how much worse. Certainly, claims that Qt/Embedded is smaller or faster than X11-based environments are just erroneous.
Also, there is no KDE flab in Qtopia AFAIK, it's just QT based.
I didn't claim that Qtopia was based on KDE. Please read my message more carefully.
I suspect the Agenda 75Kbyte window manager doesn't provide all those features. How much ram is used on the agenda once you start up all the extra processes to provide that funcionality?
The entire Agenda VR has 8Mbytes of RAM. In that, it runs, comfortably, X11, the window manager, several input methods (keyboard, character recognition), IrDA support, and standard PDA apps.
My overall point is simply this: unlike what people claim, Qt/Embedded is just not an improvement on X11-based handheld environments in terms of either size or performance.
That doesn't mean it's a bad environment. (Actually, if the world needed another Palm-like, all-integrated environment, it would be pretty nice, but I think the world doesn't.) It just means that people should stop making erroneous claims about X11-based handhelds--technically, I see no justification for the existence of Qt/Embedded.
And I personally find the fact that Qt/Embedded doesn't work with standard X11 applications a major problem for my needs. And that is why, as I pointed out, I won't be upgrading my SL-5500.
And that's good as far as I'm concerned--Microsoft is too quick force every idea they have down people's throats and to build huge monolithic systems around unproven ideas and codebases. That's the problem with large, centralized development efforts. Linux isn't entirely immune from it (the kernel, Gnome, and KDE are showing some of those problems), but it's still much better and much more decentralized.
Let people worry a few more years about DirectX and OpenGL 2 features and see how things shake out; then, those things may be mature enough to be widely used and built on. Until then, a good OpenGL 1.x implementation is all I want.
Re:here are the facts (Qt/Embedded vs. X11)
on
Zaurus 5600 Announced
·
· Score: 3, Informative
Yeah, plus widget set (another 2-3 MB) , plus nice network C++ wrapper ( another 0.5 MB) + nice XML wrapper (1 MB) + nice set of generic containers ( 0.5 MB).
There is no "plus". I gave RSS sizes. Those include all the memory that an application actually uses.
However, if you want to compare shared library sizes, FLTK is a 423kbyte library, and FLEK (sockets, XML, dates, files, math, etc.) is another 282kbytes; the Qt/Embedded equivalents are more than five times larger.
Please, obviously you never wrote a single line of code , for otherwise you would know that raw X11 is pretty much useless as afar as app programming goes.
You just demonstrate again that you jump to conclusions without any factual knowledge.
No to mention the fact that with X11 one usually ends up with multiple set of widget libs since which would be a complete nonsense on a device like the Zaurus.
It's not "nonsense" at all. The main attraction of Linux handhelds is that they require less porting. That means, I want the option of using an existing toolkit if it makes sense, I don't want to be dictated to which toolkit to use. If I have to rewrite the entire GUI anyway, I might as well port to PocketPC or Palm and get a much bigger user base.
Now how said that ? QT/Embedded was supoosed to cut out the flab from X11/KDE and just port the GUI withut the extra flab, and now you say X11 uses less space ?
The "flab" comes from KDE/Qt, not X11. And it simply turns out that KDE/Qt with flab removed is still much more heavy-weight than X11 with a toolkit that's actually efficient.
Please before you comment like a supposed expert please check out your facts.
I know my facts, but you apparently don't. It's people like you who just mindlessly repeat what some company tells them that are the problem.
These are the facts, measured on my Zaurus and Agenda VR:
For the resident set size of Qt/Embedded, we get: qpe process, 6.7Mbytes, embeddedconsole, 3.8Mbytes, addressbook, 3.9Mbytes, etc.
For the resident set size of X11, we get: X11 server, 1.1Mbytes, window manager, 75kbytes, Terminal, 204kbytes. (Similar numbers for X11 on Zaurus hardware.)
Qt/Embedded also seems a lot slower than X11, although I haven't done actual measurements.
Altogether, just because some company tells you that their product is better or more efficient doesn't mean that it is. Go check for yourself if you don't believe me.
Slashdot Mirror
But, referring to doing this on native Windows code is not a good idea at all. Remember the EULA, simply having the Windows code on your disk constitutes acceptance of the EULA and reverse engineering by assembly dumps is explicitly defined as a violation of the EULA. In other words you are setting yourself in a position for major legal problems.
Don't believe everything you read. Just because Bill Gates writes into the EULA that you'll work as his towel boy if you open the box doesn't mean you are actually legally obligated to.
The only legitimate way to reverse engineer software is the method used by the Samba team. You must look at the input and look at the output and then determine your OWN method of achieving the same result.
Sorry, but you don't know what you are talking about. That is not "the only legitimate way".
Thus ANYTHING that you produce afterwards the even vaguely resembles the operation of the original software will place you in a losing position, legally
Oh, please, stop the hysteria. These things need to judged on a case-by-case basis. I frankly doubt that reverse engineering a trojan/virus will get you into hot water with Microsoft's EULA.
The lack of authoring tools for SVG may actually turn out to be an advantage. People doing Flash seem to be mostly using it for things that are very annoying to users, and they are often not doing it very well (that flashing, blinking web interface doesn't resize, for example). SVG may turn out to be a better and more acceptable format for vector graphics than Flash precisely because the people who shouldn't use it don't know how to anyway (of course, that blessed state will not last long--if it catches on, Macromedia will output SVG, too).
But until SVG becomes supported out of the box, with no plugins, by IE and Mozilla, it won't catch on much. Microsoft may support SVG in IE just to spite Macromedia--let's hope so. But it is incomprehensible to me why Mozilla has been so slow to offer SVG support: it already has all the XML parsing and graphics primitives built in--why is SVG support so difficult?
I don't see why this kind of thing should cause revulsion. Ants are extremely useful and interesting and they are usually harmless. If there is anything disturbing about this it's that such useful critters needed to be destroyed.
If a new product or technology wants to replace an existing (and dominant) incumbent, then it has to make the transition as easy as possible or present an extremely compelling reason why it shouldn't. [...] While you may believe that your product is "worth it", unless your potential customers believe it as well, they aren't going to switch.
My point is: I don't want you to convince you to switch, nor do I want to hack up my software to make it easier for you to switch. What I do want you and anybody else to do is not to be guided by misconceptions when choosing software or to influence Linux software development to become more of a Windows clone.
It is perfectly legitimate to say "I'm going to stay with Photoshop because I know it and because it works for me". It is, however, irrational and counterproductive to approach the issue by saying "Linux imaging software is no good because it doesn't work like Photoshop".
The problem with free software is that nobody is interested in convincing other people to switch. The developers of free software are doing so predominantly for their own benefit ("I want to make a tool easier for me to use"), and while that ability is a major plus for some people, it shouldn't be any surprise that "regular" people aren't impressed with the results. After all, they aren't catered to, as they are with "commercial" software.
I don't see this as a problem, I see it as a strength. I don't want software design to be driven by marketing considerations. And I definitely don't want open source software to behave like Windows software--if I wanted to use Windows, I would be using it.
You'll probably see pretty cheap (my guess is $20-$50) Bluetooth serial dongles coming out in 2003. And, of course, you can already get unpackaged Bluetooth modules from Ericsson that effectively have a Bluetooth connector. And you'll probably see more PICs with Bluetooth capabilities. Those are likely to be a more convenient and robust solution than special-purpose 900MHz serial hacks. They will also allow you to talk to the serial devices from any Bluetooth dongle, not just a proprietary one.
You can, of course, already get Bluetooth USB dongles for around $30. Those are really great little pieces of hardware, and you can stick them on just about any computer that needs to communicate wirelessly.
I seriously doubt that the boards that GENRIP works with are "ultra low-cost". Their web site doesn't have any prices that I could see, and these kinds of boards tend to be costly.
I think Windows is a piece of junk as an operating system. But there is software that only runs on Windows, so I have a low-end Windows laptop sitting around (I can also dual-boot my Linux machine). One of the best applications (relatively speaking) on Windows is IE--it's a decent web browser, and since the Windows laptop isn't good for much else, I use it for web browsing.
No matter how fast they make the drivers, no matter how much they optimize it - a client-server based desktop environment is ALWAYS going to be slower than a non-c/s solution.
First of all, there are almost no "non-c/s" window systems left. Windows and Mac OS X are both "client server" windowing systems as well--all multiprocess windowing systems need a server to handle interaction among multiple applications. And, in fact, neither Windows nor Mac OS X applications draw to the screen directly either: in the case of Windows, they call a GDI server in the kernel, and in the case of Mac OS X, they generate PDF that gets sent to a server. Last I did benchmarks, X11 beat both Windows and the Mac OS X GUI handily in terms of performance on comparable hardware (although there certainly are going to be some graphics cards for which Windows outperforms X11, depending on driver quality).
Second, it just isn't true that "client server" is always slower than a "non client server" solution. As just one simple example, if you run X11 on a dual processor machine, you automatically get parallelism, where the application and the display code run on separate processors.
In addition, modern window systems can't help but be client/server: graphics chips have their own processors; applications effectively draw by sending requests to those graphics chips. Putting pixels directly into the framebuffer is very slow.
Finally, if anybody felt that direct rendering was important for writing a fast GUI toolkit for X11, X11 supports it: you can use DRI and fiddle around with on-screen bits as much as you like. Toolkits don't do that because it just doesn't make sense for a general purpose toolkit.
X continues to feel just a bit sluggardly on all my systems, even with the latest, fanciest drivers from whoever.
Well, the most likely cause of that is not X11 but your chosen desktop environment. For example, if you are running Gnome or KDE, that's the source of your performance problems. Those environments (and their toolkits) impose enormous and unnecessary overhead. They don't use a lot of the rendering facilities available natively in X11 and do a lot of rendering in software and then blit it to the screen. Of course, most people aren't bothered by that because even with their overhead, Gnome and KDE are fast enough on modern hardware.
The second biggest problem I have with Linux is stability. Linux itself is a rock, but I have not used a single X app that hasn't crashed at least once. It's a dismal record.
Well, you seem to be using the wrong applications, then. There are buggy GUI apps on any platform. On X11, at least you are guaranteed that a buggy GUI app can't take down the whole window system. And because X11 is a protocol rather than an API, you can eliminate the most likely cause of crashes from your programs entirely: C-based APIs. Languages like Lisp, Java, and ML have bindings to X11 that are entirely free of C code.
X11 is far more stable as a window system than anything else I have seen, and it's by far the best architecture around for building stable GUI apps because it separates the display code from the client code so cleanly (DisplayPDF and DisplayPostscript come close). The fact that there are some big and vocal projects producing buggy clients for X11 isn't X11's fault. Judging the stability of X11 by the stability of some free clients is like judging the stability of Windows by the stability of shareware apps you download.
I don't see how it's ever going to do it relying on X, and I don't see the desktop environments coming anywhere near more polished corporate-funded alternative
X11 is one of the biggest strengths of Linux. If it didn't exist, it would have to be invented.
And X11 is widely used in corporations and businesses, in particular in mission-critical applications like banking.
Ditch X and come up with a really solid desktop environment that doesn't require it, and I'll be back in a heartbeat.
We can't make everybody happy all of the time. So, have fun with Windows. You won't be missed.
What keeps you using Photoshop is the same that keeps other people using Windows: you are used to certain tools, they get your job done, and you don't want to spend the time learning something new. There is nothing wrong with that. But that's your problem, not a problem with Linux or Linux applications.
Having been in digital imaging for 20 years, I assure you that Linux and UNIX are an excellent platform for digital imaging. In fact, once you learn the tools, it's a lot better than Photoshop or Windows in my opinion. I have used Photoshop, and you couldn't pay me to switch to it: it's just the usual, bloated, monolithic software style that is so common on Windows.
IEEE seems to be good at sharing infromation, with a few small problems.See their terms and conditions [ieee.org] for yourself.
That link points to their web site copyright, and the other link you give is a "web publishing howto" with no relationship to their scientific and engineering publications.
If you want to know what their scientific publishing policies are, take a look at their copyright transfer form: like other scientific publishers, they require you to transfer your copyright to them and severely limit your own rights to reusing the content.
There are some publications (mostly peer-reviewed on-line journals) that are trying to break the stranglehold of such agreements. They don't require copyright transfer, but just ask you for a license that lets them republish your work to which you retain the copyright.
Peer review is part of active research and should be thought of as part of any research position. It keeps you up to date and sharpens your brain
It is and it does. But since publishers get the peer review for free, by far the most valuable part of scientific publishing, they should then not charge huge amounts of money for the publications themselves.
In particular, it is incomprehensible why a non-profit organization like the IEEE should charge anything significant for on-line access to their digital library, whose contents were created, reviewed, and edited almost entirely by volunteers, and whose creation is more than paid for already by the high charges for the print publications.
In fact, if you retained the copyright, competition would easily take care of price gouging in scientific publishing, since publishers that overcharge would face competition from publishers that don't and end up reprinting the same works.
The burden of clerical work is a different and unrelated issue. You should have an expert at digital publishing who can take your plain text, raw data and notes on equations, and turn them into decent looking papers on the web and on paper trough Apache, LaTex, DX and any other useful system. Secrataries should be up to this task. Anything else is wasteful of real research time.
Secretaries? Maybe there are still a few plush places that have those, but no real-world place has those anymore. Most researchers have administrative assistants, and they don't do typing or type setting.
In any case, that's besides the point. The point is that publishers often don't even do the type setting and layout anymore themselves either, which again raises the question of what they actually are charging all that money for.
If you want to know the most likely legal reason why they couldn't sue the government over this, see my other posting.
The government pays Dr. Smith to write a scientific article. Dr. Smith gives the article to a scientific publisher and receives no compensation. That's the same publisher that Dr. Smith also puts in many hours in unpaid editorial work. The government puts Dr. Smith's paper on the web. The publisher, who contributed nothing to either the creation or the editing of the article, complains about this. They have neither a legal leg to stand on (the government refuses to sign over the copyright--they are big enough to be accomodated), nor do they have an ethical leg to stand on (the publishers contributed nothing to the content).
It gets even worse for educational or private researcher. Prof. Johnson writes a scientific article and needs to get it published in order to get tenure. The IEEE or Springer or whoever says: we only publish this article if you sign away all your rights to it and then some. Prof. Johnson also needs an editorial board position on his resume to get tenure, so he puts in many more unpaid hours doing editing, reviewing, and clerical work for the publisher.
Scientific publishing is a racket similar to the mafia. The only difference is that scientific publishers don't kill you with a bullet; it's just if you don't cooperate and put in hundreds of thousands of dollars worth of specialized, unpaid labor, your scientific career is over.
So, there you have your answer. For the DivX, the legal and ethical copyright holder complains. For the scientific articles, companies with no legal or ethical basis flex their political muscle and get their way. It's pretty disgusting.
Just like we're not allowed to sell things for less than they cost, the DOE should not be allowed to do this.
Quite to the contrary. It is actually the primary function of governments to give us services at a price that would be unaffordable for the people who need them if they were made available by the market. You or I can't afford to buy police protection, or highways, or a military on the open market, but we need those services, and we elect our government to provide them to us outside the usual market mechanisms.
When it comes to scientific literature, society has a compelling interest in divorcing its availability from market sources. It should not cost $15 or $40 to get a research article. If it does, publishers are either price gouging, or they simple can't provide the service at the price that researchers can pay. Either way, the government has a strong interest to step in.
What is particularly galling about this is that the publishers actually pay nothing for the content: the content is created by researchers often paid for by the government or industry, and all the reviewing and editing is also done for free by volunteers. Authors even typeset the stuff themselves these days. If anybody is "stealing", it's the scientific publishers.
Because it writes directly to the framebuffer, instead of passing things around to someone else and asking them to write it.
Ummm--how exactly does "asking someone else" use more memory? What do you think uses that memory?
Client/Server always involves more overhead
Quite to the contrary. For example, 100 PCs running Windows require a lot more memory and CPU power to get the same work done as single server with 100 terminals.
It's similar with X11. Because it carefully separates concerns, X11 clients can be incredibly simple and lightweight (of course, Qt/X11 and Gtk+/X11 are dogs, but that's a different story). Some X11 clients run on 8bit micros and take as little as a few hundred bytes of code and data combined. Having all the graphics happen in a single process, like in X11, also makes things much smaller and simpler on the server side.
On the other hand, mapping the frame buffer and putting graphics code in every client, like Qt/Embedded does, involves a lot of overhead, duplicated data structures, and duplicated code.
Abstracting things out into different layers always adds more overhead.
Premature optimization is the root of most performance problems and bugs, and Qt/Embedded is another example of that. A good architecture beats a hack almost always.
Yes, that's how Linux e-mail applications work. What's your point?
Handwriting recognition is the killer feature here and Microsoft has done tons of research on this. Check out the Microsoft Research website.
Microsoft has hired a bunch of good people over the years, but there is nothing special about Microsoft's handwriting recognition efforts or technology: lots of people understand how to do something that's pretty close to state-of-the-art, and nobody (not Microsoft, not anybody else) has implemented a completely satisfactory system.
Handwriting recognition used to be a hard engineering problem on machines like the Newton, which were slow and had limited amounts of memory, but that's not a big deal anymore with modern tablets.
"tappable" is a word, formed using standard rules from "tap" and "-able". It's in some use: try searching for "tappable" and "tappable keyboard" on Google. Dictionaries don't usually list derived words like this whose meaning is obvious to most native speakers.
Did I just miss it in the article? I can't find any link to the company, nor any reference to the company or product anywhere else on the web. Does anybody know more? $800 really is a good deal on a pen-based computer, and this thing should have lots of applications, if not in the consumer area, then in vertical markets.
There is plenty of Linux software designed to run with pen input--after all, Linux has been used on handhelds for a number of years.
Most mouse based applications work naturally with a pen anyway. Web browsing, e-book reading, marking up text, drawing, and things like that work like a charm with standard Linux applications on a Linux-based tablet. And even with no handwriting recognition, an on-screen keyboard makes entering text and data quite easy and quick and, again, requires no application changes (given the modular X11 architecture). And fully integrated handwriting and gesture recognition also already exists for X11.
Maybe it was a lot of work to integrate pen input into Windows, but Linux and X11 are modular and mature enough that this is not an issue.
And many functions of pen computers don't require handwriting recognition at all (ink notes, browsing, e-books, etc.)--just getting rid of that bulky keyboard alone when it's not needed would be worth the pen computer.
Lets suppose we decided you were right, and instead of using QTEmbedded on top of the linux framebuffer, we used regular QT and stuck an X11 server inbetween QT and the linux frame buffer. You are saying this X11 solution is a ligherweight solution than QT straight on the framebuffer?
Why shouldn't it be? Why should "sticking a process inbetween" use a lot more memory? Even all things being equal, except for a process table entry and a small IPC buffer, what memory do you believe a client/server approach requires compared to a frame buffer library?
And, in fact, QPE requires multiple processes and inter-process communication just like X11--that's because, just like X11, it runs on a multitasking OS and supports multiple clients, and the clients need to coordinate window management. The only difference is that in Qt/Embedded each application writes to the frame buffer directly for low-level drawing, while in X11, drawing operations are sent as IPC messages to the window server by default (with direct rendering an option). Basically, Qt/Embedded is just like X11 using DRI for rendering.
So, come on, be specific and concrete: where exactly is the Qt/Embedded architecture supposed to save memory compared to the X11 architecture? Tell us.
Overheard in the executive suite: "Well, let's see, if we pay $50m to each of us as bonuses and $20m to the investors, there is just no profit left. Strange how that works out, isn't it."
Well, your reading is wrong. The "flab" I was referring to was the "flab" that was "cut out", not the bloat that remains in QPE and Qt/Embedded after all the "flab" was removed.
The QPE process alone is using 1.7Mb, not 6.7Mb. The rest is shared libraries.
No. The 6.7Mbytes is the resident set size, i.e., the amount of RAM that the QPE process needs to run. Yes, that includes portions of shared libraries that the process needs to run (it also does on the Agenda numbers), so let's say for the sake of argument that all other processes combined use no memory whatsoever--that way we can be certain that we count not a single byte twice. Then, the QPE process uses more memory than the entire Agenda software environment uses, including X11 server, toolkit, input methods, task bar, wireless LAN monitors, desktop synchronization, etc. The Agenda only has 8Mbytes. And the numbers are roughly the same if you run X11 on the Zaurus.
No matter how you apportion it, QPE is worse than X11 in terms of resource usage. Face the facts.
If you want to say which is smaller you either need to compare the agenda X11 + window manager with a stripped down QPE with no application launcher, no task bar, no input methods, no wireless lan monitors, no desktop syncronisation code etc etc etc.
I stated what I compared.
Does comparing XFree86 + twm + xterm with KDE make much sense? twm is 50 times smaller than KDE, twm must be better right?
Well, it is the Qt/Embedded proponents that claim that smaller is better, not me. I merely point out that Qt/Embedded happens to be pretty heavyweight, in particular compared to X11.
As for speed, i have seen no benchmarks myself, and you have provided none, so in the meantime i'll presume such claims as "X11 is faster than QT" are pure speculation
They are not "speculation", they are observation, as I indicated. I have a Zaurus (as well as several other handhelds), and I have run the window systems on identical hardware. It is also my observationthat QPE or Qt/Embedded is susceptible to focus problems that require a reboot--not good on handhelds.
Fair enough, but i suspect Sharp doesn't see that as much of a market, the average PDA user doesn't know or care what X11 is.
Based on actually using it, I think the "average PDA user" would be a fool to buy a Zaurus. A Palm is a much better handheld for day-to-day PDA usage: it's smaller, it's lighter, it's better supported, it's cheaper, and it interfaces better with Windows, OS X, and (ironically) Linux. The only area where Linux-based PDAs can shine is for software development, but the Zaurus GUI is incompatible with all Linux and UNIX toolkits and desktop environments except one. In my opinion, the Zaurus has no future, at least in the US market: it's not a good consumer device, and it's not a good device for hackers.
In any case, all I said is that I won't be ugprading my SL-5500, and I gave the reasons why. You are free to waste your money in whatever way you like.
Well, given that the QPE process alone is several times as large as X11, the window manager, and the terminal application combined, the question really isn't whether Qt/Embedded is worse in terms of resource usage than X11, but only how much worse. Certainly, claims that Qt/Embedded is smaller or faster than X11-based environments are just erroneous.
Also, there is no KDE flab in Qtopia AFAIK, it's just QT based.
I didn't claim that Qtopia was based on KDE. Please read my message more carefully.
I suspect the Agenda 75Kbyte window manager doesn't provide all those features. How much ram is used on the agenda once you start up all the extra processes to provide that funcionality?
The entire Agenda VR has 8Mbytes of RAM. In that, it runs, comfortably, X11, the window manager, several input methods (keyboard, character recognition), IrDA support, and standard PDA apps.
My overall point is simply this: unlike what people claim, Qt/Embedded is just not an improvement on X11-based handheld environments in terms of either size or performance.
That doesn't mean it's a bad environment. (Actually, if the world needed another Palm-like, all-integrated environment, it would be pretty nice, but I think the world doesn't.) It just means that people should stop making erroneous claims about X11-based handhelds--technically, I see no justification for the existence of Qt/Embedded.
And I personally find the fact that Qt/Embedded doesn't work with standard X11 applications a major problem for my needs. And that is why, as I pointed out, I won't be upgrading my SL-5500.
Let people worry a few more years about DirectX and OpenGL 2 features and see how things shake out; then, those things may be mature enough to be widely used and built on. Until then, a good OpenGL 1.x implementation is all I want.
There is no "plus". I gave RSS sizes. Those include all the memory that an application actually uses.
However, if you want to compare shared library sizes, FLTK is a 423kbyte library, and FLEK (sockets, XML, dates, files, math, etc.) is another 282kbytes; the Qt/Embedded equivalents are more than five times larger.
Please, obviously you never wrote a single line of code , for otherwise you would know that raw X11 is pretty much useless as afar as app programming goes.
You just demonstrate again that you jump to conclusions without any factual knowledge.
No to mention the fact that with X11 one usually ends up with multiple set of widget libs since which would be a complete nonsense on a device like the Zaurus.
It's not "nonsense" at all. The main attraction of Linux handhelds is that they require less porting. That means, I want the option of using an existing toolkit if it makes sense, I don't want to be dictated to which toolkit to use. If I have to rewrite the entire GUI anyway, I might as well port to PocketPC or Palm and get a much bigger user base.
The "flab" comes from KDE/Qt, not X11. And it simply turns out that KDE/Qt with flab removed is still much more heavy-weight than X11 with a toolkit that's actually efficient.
Please before you comment like a supposed expert please check out your facts.
I know my facts, but you apparently don't. It's people like you who just mindlessly repeat what some company tells them that are the problem.
These are the facts, measured on my Zaurus and Agenda VR:
- For the resident set size of Qt/Embedded, we get: qpe process, 6.7Mbytes, embeddedconsole, 3.8Mbytes, addressbook, 3.9Mbytes, etc.
- For the resident set size of X11, we get: X11 server, 1.1Mbytes, window manager, 75kbytes, Terminal, 204kbytes. (Similar numbers for X11 on Zaurus hardware.)
Qt/Embedded also seems a lot slower than X11, although I haven't done actual measurements.Altogether, just because some company tells you that their product is better or more efficient doesn't mean that it is. Go check for yourself if you don't believe me.