Wiretapping means you attach a device to someone else's wire and read data from it. It implies there is an invasion of privacy, as someone learns information that he wasn't meant to hear.
However, many state laws define wiretapping as "electronically recording someone's voice without his knowledge". It has been used to indict people for recording what they believed were crimes by police. In certain jurisdictions, it may be even worse: wiretapping only applies to "audio recordings", so peeking on someone's video signal might not be covered.
I've heard that some cops have sometimes wiretapped suspects' phones in advance of getting a warrant. They can listen in, and are legally protected by not starting the tape-recorder. (Probably couldn't use evidence gained, but they don't always want evidence)
That's consistent with the intent of copyright law, so I understand why you'd think so. But you're wrong! Read entry #2, it directly contradicts you. Stop living in the 70s- today everything is copyrighted as soon as pen hits paper. (entry 4 on the same page)
Publication has nothing to do with it. There was a successful copyright-infringment lawsuit brought against burglars who invaded someone's property and privacy to steal notes. (I don't have a link, but its true. It seems strange that someone would press minor charges in place of blatant criminal conviction, but we can imagine some reasons)
You can't judge a book by its cover, and you can't interpret a law by its name. Don't point to the word "Copyright" in the name of the DMCA and assume it only tries to enforce the original meaning of copyright. After all, if the government had only wanted to enforce an existing law, instead of increasing it's scope, then why did it need to pass a new law?
Reading the DMCA, we see that it forbids "circumvention of mechanisms used to protect copyrighted content". It doesn't matter whether the mechanism is currently being used for something copyrighted or not- you still can't break their protection. Creation, possession or distribution of circumvention devices is illegal too. This means that by wrapping a work in a protection mechanism, even a trivially weak one, publishers can effectively write their own copyright laws- ones without revenue-damaging drawbacks like fair use, extraction of facts, and eventual expiration.
Hopefully, because it goes so much further than it reasonably should, the DMCA will be overturned. Then your common-sense ideas may start to have some validity again.
Of course, the software architects will say "Moving menus (or other widgets) into the X protocol violates layering. Those higher-level objects belong in toolkit libraries."
And really, "extend X" can be interpreted as either a protocol extension, or just building a feature in a library on top of it. The effect can be the same, if the toolkit is pervasive enough to be usually available (but no current toolkit is that dominant). And if an extension were made, the application programers would still have use toolkit functions to set up menus- because if the Xserver doesn't allow that extension, somebody's still got to draw a menu on top of the window.
So, the 2 possible implementations: "an X-protocol extension which might be present, but can also be emulated by the toolkit" or "a helper program which might be running, but can also be emulated by the toolkit" are fairly equivalent. Both of them could let menus be positioned in theme-specific ways, and neither would break the applications if it isn't present.
But a helper program has a big advantage over a protocol extension: You can actually install it without modifying the Xserver. That means it can work with closed-source Xservers that can't be modified, or on desktop systems whose software you don't want to alter. In fact, the toolkit could even execute the helper-program if it can't find one running. Since the toolkit can be linked right into the apps that need it, deployment concerns are even less important.
In fact, some toolkits do this, when in conjunction with their own window-manager/control panel. (I'm sure you already knew that.) I'm only aware of that being done in conjunction with helper-programs that are much more bloated than a simple menu-drawer, though. (Good discussion of a few of the many concerns here).
trying to put across (and this is a hard one to pin down, let alone argue properly) is that X puts its 'abstraction layer(s)' in the wrong place.
Let me attempt a concise description of the problem (which is broader than X11 vs PicoGui, and is really about low-level display protocols vs higher-level ones):
For any client/network/server hardware, there is one best way to divide up the portions of a client-server application so that users get the best performance. If the network is fast, then transmitting every single pixel from the server might work OK. If the network is slow but the client system is fast, then loading most of the program into a Java applet for local execution might be best. The optimal choice varies according to the application and the hardware resources available. There's no one best solution.
If a program is written with low-level tools, then the programmer must decide on an approach during development. He can do what's best for his hardware, but the solution is hard-coded, and might not be portable to other clients/networks. But, if the application were developed with a higher-level toolkit, then the optimization to adapt to a different client capabilities and network bandwidth can be done and redone automatically, as much as needed to track changes. (Even if the process isn't automatic, manual reconfiguration of some options is faster than rewriting the whole app)
This is analogous to the argument about programming in assmebly language vs C. Writing a program in assembly for the 8088 could give you better speed than C (assuming you're truely a master coder, or your C compiler is poor). But then when the program is brought to a 386 it will be much slower than a C program recompiled for the new processor, because the relative execution latencies of the opcodes have changed.
Going low-level ("writing to the metal") can give better results for a certain situation, if the implementor is an expert. But high-level techniques allow more flexiblity later, as well as protecting users from the mistakes of inexpert application developers.
That's pretty much what I said when I started this conversation. This topic is too old for me to reiterate anymore, though. And the discussion of X's quality gets confused when the sides agree neither on the extent (X as a developer's protocol or as a user's platform) nor scope (nearterm practicalities vs longterm goals). I always take the long view and theorize on solutions that in 20 years may give us interfaces resembling those portrayed in contemporary science-fiction films. This may be misinterpreted by someone only interested in code he can deploy next week.
Someday there may be a replacement for "buttons" and "menus" and "icons" that is far more user friendly (no, I don't know what, if I did I would be writing it!) and when that happens the people who wrote toolkits into the system are going to look as stupid
If they used a traditional button/menu/icon toolkit then they'd have some re-writing to do, yes. But everyone uses toolkits like that today, and they'll all have the problem. OTOH, if in the meantime some people develop and code to a higher-level toolkit (where the application programmer doesn't think in terms of "menus" and "icons" but in "commands", "properties" and "relations"), then they might be able to just update the toolkit to the new paradigm.and find the applications automatically working.
arbitrary transformation of an image with error diffusion, something we have known how to do since about 1987 but for some reason is not in any of the graphics systems even today
Really? Apple claims their new onscreen drawing system is all a 2d programmer could ever want. Floating-point coordinates, arbitrary transformation, and antialiasing. You think it's still not good enough?
PS. So I install this Oroboros XDarwin server on a MacOSX system, ssh to a linux box and remote-display some fltk programs, and everything's fine. Then I recompile them on the Mac and run it locally- the picture shows up, and mouseclicks are recognized, but the program can never get focus. So it can never recieve keystrokes.
The gorilla arm syndrome was caused by the combination of touchscreens with boxy, CRT monitors. Now that LCDs can be laid flat on a desk/lap, the strain on your arms will be similar to operating a mouse or pencil.
That post was difficult to read because it uses the X11 definitions of "server" and "client", which are backwards from the usages in VNC, http, UT, and every other client/server GUI framework. That's the reverse of what grandparent had used, but I'll do the X11 defintions below. (Or prehaps viewer/backend would be a more obvious pair of words)
Under the "very high level" approach, the server will just pop up an edit widget here and everything will happen on the server side.
That's just fine.
Now, consider this with the arbitrary disconnect requirement. The wire may be cut at any time,
Where did "arbitrary disconnect" come from? The word I used was "detach", which is a subset of arb-discon. I never implied that a user should be able to just yank out her phone line at any point. To "detach" can require an orderly shut down of the connection (initiated on either side).
Restricting your protocol design to the assumption that the TCP connection can be broken at any time is a mistake, because in normal use such a failure will be rather rare. "Optimize for the common case". Most connections will be terminated by a proper shutdown of the viewer. Of the fraction of connections that break by other means, most will have been after a decent period of user inactivity. Only a surprise hardware failure will cause this kind of instant disconnection.
There's no need to resynchronize after every single edit on the viewer. As you've said, the penalties would be enormous. Waiting 10-30 seconds will be good enough, and it won't break any assumptions users have with operating computers. People today fully accept that if their hardware fails, the editing they've done since the last explicit "save" command will be gone. (If they can get back a portion of the modifications- suitably flagged as "recovered auto-save data"- then they see it as a bonus)
Forbidding unannounced connection-breakage is a small price to pay for maintaining some of that "elegant simplicity".
even faster and snappier, though: TightVNC. With 8-bit mode and compression, it's completely usable and has almost no discernible latency over my cable modem line.
Funny, over my 10mbps ethernet line I use X11 with no apparent latency. But to access MS Windows machines on the same network I've tried VNC (in 3 formats- normal, Tight, and some other name), and it wasn't ever usable. This may be application-specific (Microsoft Word was hopeless)
Let me point out a simple higher-level protocol that's much faster than X11 or VNC: rsh/ssh (or telnet). I'm sure you know that if you're going to run console-based programs, creating a local console and ssh-ing to the host computer will be terribly faster and more responsive than transmitting a remote xterm over ssh -X. That kind of performance advantage is what a well-designed higher-level graphics protocol could eventually give us.
In an even higher level system like picogui, this will be even harder still.
Totally wrong. The only reason detachment was hard for X is because the designers didn't plan for it. In a higher level system, you could not only detach more easily, but with less wasting of resources. There'd be no need to maintain bitmapped images of all your programs when they're not in use- the GUI system can regenerate those when the user next becomes active.
In general, the higher-level an API is, the easier it will be for new features (like detachment or network transparency) to be slipped into the system without breaking existing users. This is getting towards one of the benefits of the "OSes are irrelevant" story, which was similarly hijacked by an inflammatory article-title.
The kind of network-transparency I'd like to see someday includes client-side knowledge of what a pressable-button is and what a scrollbar does. If the client knows that movement of a scrollbar is bound towards the Y offset of a picture in a frame, then as long as the picture has already been buffered, up-down scrolling can be a completely client-side operation. The only data going back to the server is a 16-bit new Y coordinate, and nothing has to come from it at all. (Of course you can get into some complicated management of just how long the client should maintain caches of offscreen images, but the high-level protocl designers can worry about that).
Imagine I'm using a higher-level protocol to run a program on a remote machine and scroll down a long document. The client is keeping a cache of the graphical image of part of the document- not just the section I'm currently viewing, but what I've recently seen, and what I'm about to see. The system could assume that someone looking at page 4 will soon look at page 5, and pre-buffer it so that when I do hit the scrollbar, redraw is instantaneous. No lower-level protocol will ever be able to make that kind of optimization.
A much better idea might be to invest in some cleanup efforts in X11 itself. For instance, the protocol is rather old and is becoming somewhat more crufty with time.
Once you start doing that though, you've no longer got "X11". Eliminate any part of the protocol, and the backwards compatibility that is X11's biggest advantage is gone. You'd be essentially creating a new protocol by reusing X's ideas and code. That would be an even harder sell to the app developer community, because in the end it varies so little from existing X.
to implement the X protocol stream. And once you do that, ta-da you're an X server once again, just like XFree86.
How do the Object-Oriented guys say it? Containing or implementing X is not the same as being X. Microsoft's Windows GDI and Apple's Aqua are "backwards compatible" with X11 in the sense that you can install and run an XServer on top of them. But they're not "an X server again".
current UNIX ports of OpenOffice and Mozilla Both OpenOffice and Mozilla run on non-X11 GUIs, I think. So some of the work of migrating them to another GUI has already been done. Likewise both the Gtk and Qt toolkits can run without X11. This point isn't insurmountable. (Although, to take proper advantage of newer GUI abstractions you'd have to re-write a lot of code anyway, because the way a user interacts with the application is going to be different).
one of the biggest benefits of X: the X protocol stream and the client/server model. D'oh!
Its a benefit, and also a hinderance. Many people are not served by this client server model. On one side are people who claim that "I'm sitting right at the computer, why should there be a network-protocol abstraction getting in the way of raw performance?". On the other side are those who want network transparency but find that X is too bandwidth intensive to be usable.
Ever try running X11 programs across the modern internet? It's very painful (unless you have some amazingly fat fast pipe). A simple "ls" in a remotely displayed xterm seems to take forever. But yet, gorgeous online games like Counterstrike and Warcraft are fast and snappy. Of course this is because the games are communicating at a much higher level than the X drawing primitives do. With newer, higher-level GUI APIs, more applications might be able to get this kind of benefit. It all depends on where in the application you define the partition between stuff running on the client and the server. PicoGui tries to run more of the GUI parts on the client-side, reducing the bandwidth needed to keep the program going.
(Related historical half-truth: the Java language was originally meant to be platform independent so that the partition between the client/server parts of a program could be determined at runtime, to best match the computing and network hardware on both sides of the link.)
X is not going away.
Not for a long time. It is absolutely true that the biggest advantage to staying with X11 is inertial- the big mass of existing applications. But at some point one will always need to break with the past. Today we can plan where to go, even if the trip isn't practical yet.
I don't disagree with the point you're inexpertly trying to make, but you're doing a terrible job.
No one else was making the point. True, I didn't have time to write much. But a barrage of "X is fine! You just don't understand X" posts had already started, and there was nothing better up to defend the idea of a next-generation GUI.
on Windows you've got OWL and MFC for starters
Does anyone really use OWL anymore? You're sure not going to earn a "Optimized For Windows XP" logo with those kinds of buttons!
you're misunderstanding the scope of X11
The (limited) scope of X11 is the problem.
But you can't argue that X11 needs to be supplanted by GTK.
Like I said, X11 is filling two roles. One role is that of a protocol, and it's fine there. The other role is that of a platform, and that's where it needs to be supplanted. Sure, we'll always have "Freedom of Choice" in that old/alternative source code won't just evaporate. But the only way the user-computer interactive process can become truely better (better than today's X11 desktops, and also the Macintosh and Microsoft offerings) is when someone creates a sufficiently powerful abstraction that application programming and GUI programming can be completely disjoint. And yes, good abstractions are hard, and PicoGui is really just a tentative step along the way, but developers need to explore this terrain if we're ever going to get a better system.
(X11 compatibility can of course be retained as legacy support for a long time)
The proper solution is to make all the higher-level widget sets interoperable. That's a harder problem.
Since PicoGui is not a widget set, one way to approach that problem is to write all widget-sets as PicoGui themes.
Why use gcj? One might assume that compiling to native binaries is faster than using a JVM, but benchmarks don't agree.
My own tests have supported this conclusion. Implementing the same simple algorithim in Sun's Javac/Java, ecj/Java and g++/C++ shows that ecj's code is not only slower than g++'s, but slower than Javac's too. My theory is that java's arithmetic primitives involve additional semantic information (like the possibility of overflow exceptions) which ecj isn't smart enough to optimize away.
GCJ programs tend to use less memory than one in a JVM, but this is an area that future JVMs can improve upon (and in general, once people start using the same VM for multiple java programs, this will get better).
Still, you can see from these comments that the primary picogui.org webpage gives people an impression of Mac-likeness. You might better advertise the project if you have more than one screenshot (with different themes) linked from the front page.
Apparently, people come in, look at the "latest screenshot", and assume its theme applies to everything.
Here we see a common pitfall of debates about the quality of X- an overloaded word. "X11R6" strictly means just a low level drawing protocol. But, in the absence of anything better, it is also means the GUI system that runs ontop of that protocol.
This same problem happens in discussions about Linux. The strict definition is an OS kernel, but "Linux" has also come to be a blanket term for the whole family of Open Source operating systems that use that kernel. "Operating System based on the Linux kernel" is too long to use in everyday speech, so it gets abbreviated down to "Linux". ("GNU/Linux" is also too long, apparently)
So then, when someone attacks Linux (the broad definition), defenders can point to the specific definiton and dismiss the complainer on the basis that he's uninformed. When this happens, the debate is cut short, without a fruitful discussion of the merits of the problem.
Back to your point. You mention that for Apple's Aqua and Microsoft's GUI there are corresponding lower level APIs: DPS and GDI respectively. But this raises the question: What higher-level system corresponds to X11R6?
There isn't one. Or there's much more than one (Xt, Athena, Motif, Qt, Gtk, XUL, Fltk, WxWindows, TK...). Neither of those answers is useful as a starting point of discussing new GUI enhancements. You can pick any one of those toolkits and consider improving it, but then you're just addressing a fraction of all users (although maybe hoping that your favorite toolkit will rise to dominance above the others).
GDI and DPS are each found inside of one and only one GUI framework (architexturally a stack of blocks, instead of the branching tree of stuff that builds on X11R6). That's a consequence of monolithic developement instead of open systems, but it makes many things simpler on the users. How do you resize a window in Microsoft Windows? The answer is straightforward. How do you close a program in MacOS X? Another simple answer. Neither of those operations is defined for X.
Only application developers are ever aware that DPS and GDI exist- they're completely hidden under the GUI. But users of X11R6 are frequently reminded of its presence. "Why isn't your program working? Did you check the DISPLAY variable? How about the xhosts? Ok, lets look at the MIT Magic Cookie..."
The world of Unix-like software can never have really great GUIs until X is invisible to average users. Maybe this means X has been supplanted by another system, or that it's just been relgated to the status of a device driver.
It's true that the competitor to PicoGui isn't X, but higher-level protocols. However the headline "An X Alternative" is not incorrect. Someday X's position as the premire "Unix GUI Application Development Platform" will be supplanted by something like Gtk, Fresco, or PicoGui. Then developers will begin to release software which runs on $NEW_DISPLAY_LAYER, rather than X directly. (Even though $NEW_DISPLAY_LAYER might still use X11R6 as a backend)
Someday a better UI environment will come around, when the only program allowed to connect to my X server is a single process from $NEW_DISPLAY_LAYER. It will enforce on applications the appearance and behavior that I want them to have, rather than leaving it up to individual authors.
Because until the late 90's desktop UNIX renaissance
The late 90's means 1997 or so. It's 2003 now, that's 6 years. And it'll surely be at least another year before RnR becomes broadly available. That's a long time. (Especially when you consider that the RnR guys only needed a few months, once they started. This suggests that writing extensions is so hard that only a select few can do it. Not encouraging)
Apple and Microsoft have both improved their GUIs enormously since 1997. X (and the other Unix graphics system, OpenGl) don't seem to have gotten much better during that time.
Since the founding of the XFree86 foundation, X has been improving at a faster rate than it has in fifteen years
XFree86 was founded in 1994. I guess I don't remember how well X worked in 1979, so I can't comment on how fast it's progressed.
Are we not changing resolutions when you "ctrl, alt, keypad +|-??????
No. Ok, maybe the monitor changes resolutions. Your desktop and all applications aren't aware of any change (like they would be in MS Windows for instance). Once you press Alt+/- in Xfree86 your entire UI experient is degraded by the constant need to shove around the viewport with the mouse cursor. That feature is worthless for anything but a quick zoom-in on an image, or for testing refresh-rate configurations.
The 8 years it took for X to get the RnR extension is an example of why so many say "X is Bad". If the extensibility is so great, then why did such an obvious improvement take so long?
(Counting from when Microsoft first introduced that feature, and including the fact that end-user desktops don't have RnR yet)
As always, what you should use depends on your needs. If X works perfectly for you, then great. As a "frame-buffer oriented network-transparent graphics API" it'd be hard to beat. As the foundation for kits like Gtk and Qt (and even PicoGui sometimes) it works well.
However, as a platform (a standard for application creation) X is sub-optimal for users and developers.
The value of a standard comes not only from what it allows you to do, but what it forbids.
Suppose I write 3 programs to perform the same tasks under different GUIs: Microsoft's, Apple's OS X Quartz/Aqua, and X11R6. A Mac user can sit down without looking at the instructions and use his familiar old mouse motions, menu commands, and keystrokes with hardly a glance at the new stuff. A Windows(tm) user has nearly the same advantages. The icons for the same feature (Save, Print) look exactly the same, regardless of the program. Of course that's not the case for X programs. Whenever I sit down at a new X11 program, I have to spend a few minutes recalibrating the basics ("How to I copy/paste, again?")
Because X allows the developer so much freedom, it deprives the user of the ability to anticipate how a program will operate. "The program can do nearly anything" sounds like an advantage, until you try to predict what a program will actually do!
Note that a weakness of Apple and Microsoft's GUI systems is that the "forbidding" part of their standard often comes in the form of "law" instead of "code". The taboos are enforced by developers getting chastised by the GUI vendor or the public when a non-ituitive program is released.
A weak method- the lag time for feedback is long, and if the offending developer works for the GUI vendor, he might insert loopholes into the rules.). But it produces superior results to X programs, where the users lack an imposing rulebook to point to as formal justification for their complaints. Improvements may happen, but there's nothing forcing them to converge on one way of doing things.
Some common responses to this argument: "You want a toolkit, not X" Maybe so. If a user's desktop could only run one toolkit, she'd never see an unfamiliar interface. This has the problem of discarding pre-existing programs, but argument-by-popularity is a logical fallacy (I'm talking about what solution would be best, not cheapest short-term). Better than using a single toolkit, though, is somehow allowing the application to be written independent of toolkit, and obeying whatever HCI conventions a particular user enjoys. PicoGui tries to do this.
"No one can be sure what the best interface is. Keeping flexibility gives us power." In theory it does, but at the expense of accessibility. Too often it means that developers who don't want to be "HCI Researchers" find themselves wrestling with UI code that's entangled their applications. PicoGui (and other "next-generation" UI systems) attempt to resolve this by keeping the application programmer further from the UI code than is traditional. (They haven't been totally successful yet) He can't mess with the per-pixel alignment of buttons, because that's outside of the application's control. This is fundamentally better than the way Apple and Microsoft's traditional Human Interface manuals have worked, because enforcement of the rules is done not by humans (punishing programs that act wrongly) but by software (doing the work for you, so it's guaranteed to do it right).
You're being far too specific here. An "engineering license" is only needed in certain jurisdictions and for certain jobs. Maybe this is true where you live, but don't assume it applies to everyone.
Many people use the word "engineer" to cover many more kinds of jobs than it really means (The strictest definition is someone who maintains an internal-combustion engine. The broad definition is someone who makes "science and math useful", which can mean anyone). So before making statements about what "engineers" have to do, its best to specify just what you mean.
Um, in the jargon of special effects, "motion controlled" means that the motion of a camera or its target (or probably both) is controlled by a computer. It's a way of filming miniature models.
Computer-generated imagery doesn't count, as there's no actual motion. Special Effects experts consider this a real difference.
You could argue that "virtual motion-control" has been performed, but that's a big stretch. The difficult part of motion control is mechanical engineering- working 100% in software lets you trivially increase the entity count by doubling your filesize + rendering time. (I could argue that I beat the world high-jump record when I played Virtua Fighter 3, too)
The Star Wars motion control record will probably stand forever, since big use of motion control is no longer cost effective to pursue.
That was a decent series- but not as good as Picket Fences. Now that's something that deserves some DVDs. The creator, David Kelley, has been TV's golden boy for the past few years. I wonder why they've never tried to put out his old stuff.
However, sci-fi/fantasy in general will have a better audience for DVD publication than a show in the "real world". Maybe not bigger, but more dedicated. A particular fan can be roped in not just by characters and story, but by technology (setting, props, costume, makeup). For nerdy folks, the opportunity to speculate on the plausibility of imaginary technology can be a big draw. (Coincidentally, nerds are more likely to collect DVDs)
This isn't what you mean, but "POSIX" is technically an OSS creation- that word was invented by RMS.
Of course neither his GNU nor Linux ever managed to implement POSIX, and POSIX can't be called an innovation anyhow. Its a standard, a codification of existing practice- nothing new.
Try again with some constructive criticism, not just criticism.
For most of these problems, there's no easy way to really fix the abstraction. The only solution is for users to be aware of the abstractions they depend on, so that they can troubleshoot the underlying foundations if things break down.
The article is constructive in that it spreads a warning to be cautious about relying on abstractions too much, without understanding how they work.
Over time processor performance buries these penalties.
Sometimes. But not all penalties can be resolved by more CPU cycles. A faster CPU can't repair your severed ethernet wire. It can't change all the existing HTML browsers and C++ compilers to cover up supposed "flaws".
And unless this CPU is awesome enough to enable real AI, it can't save us from future shortcomings in computer-interface languages either.
Slashdot Mirror
Another good example is "wiretapping laws".
Wiretapping means you attach a device to someone else's wire and read data from it. It implies there is an invasion of privacy, as someone learns information that he wasn't meant to hear.
However, many state laws define wiretapping as "electronically recording someone's voice without his knowledge". It has been used to indict people for recording what they believed were crimes by police. In certain jurisdictions, it may be even worse: wiretapping only applies to "audio recordings", so peeking on someone's video signal might not be covered.
I've heard that some cops have sometimes wiretapped suspects' phones in advance of getting a warrant. They can listen in, and are legally protected by not starting the tape-recorder. (Probably couldn't use evidence gained, but they don't always want evidence)
If it's not published, then it's not copyrighted.
That's consistent with the intent of copyright law, so I understand why you'd think so. But you're wrong! Read entry #2, it directly contradicts you. Stop living in the 70s- today everything is copyrighted as soon as pen hits paper. (entry 4 on the same page)
Publication has nothing to do with it. There was a successful copyright-infringment lawsuit brought against burglars who invaded someone's property and privacy to steal notes. (I don't have a link, but its true. It seems strange that someone would press minor charges in place of blatant criminal conviction, but we can imagine some reasons)
You can't judge a book by its cover, and you can't interpret a law by its name. Don't point to the word "Copyright" in the name of the DMCA and assume it only tries to enforce the original meaning of copyright. After all, if the government had only wanted to enforce an existing law, instead of increasing it's scope, then why did it need to pass a new law?
Reading the DMCA, we see that it forbids "circumvention of mechanisms used to protect copyrighted content". It doesn't matter whether the mechanism is currently being used for something copyrighted or not- you still can't break their protection. Creation, possession or distribution of circumvention devices is illegal too. This means that by wrapping a work in a protection mechanism, even a trivially weak one, publishers can effectively write their own copyright laws- ones without revenue-damaging drawbacks like fair use, extraction of facts, and eventual expiration.
Hopefully, because it goes so much further than it reasonably should, the DMCA will be overturned. Then your common-sense ideas may start to have some validity again.
Of course, the software architects will say "Moving menus (or other widgets) into the X protocol violates layering. Those higher-level objects belong in toolkit libraries."
And really, "extend X" can be interpreted as either a protocol extension, or just building a feature in a library on top of it. The effect can be the same, if the toolkit is pervasive enough to be usually available (but no current toolkit is that dominant). And if an extension were made, the application programers would still have use toolkit functions to set up menus- because if the Xserver doesn't allow that extension, somebody's still got to draw a menu on top of the window.
So, the 2 possible implementations: "an X-protocol extension which might be present, but can also be emulated by the toolkit" or "a helper program which might be running, but can also be emulated by the toolkit" are fairly equivalent. Both of them could let menus be positioned in theme-specific ways, and neither would break the applications if it isn't present.
But a helper program has a big advantage over a protocol extension: You can actually install it without modifying the Xserver. That means it can work with closed-source Xservers that can't be modified, or on desktop systems whose software you don't want to alter. In fact, the toolkit could even execute the helper-program if it can't find one running. Since the toolkit can be linked right into the apps that need it, deployment concerns are even less important.
In fact, some toolkits do this, when in conjunction with their own window-manager/control panel. (I'm sure you already knew that.) I'm only aware of that being done in conjunction with helper-programs that are much more bloated than a simple menu-drawer, though.
(Good discussion of a few of the many concerns here).
trying to put across (and this is a hard one to pin down, let alone argue properly) is that X puts its 'abstraction layer(s)' in the wrong place.
Let me attempt a concise description of the problem (which is broader than X11 vs PicoGui, and is really about low-level display protocols vs higher-level ones):
For any client/network/server hardware, there is one best way to divide up the portions of a client-server application so that users get the best performance. If the network is fast, then transmitting every single pixel from the server might work OK. If the network is slow but the client system is fast, then loading most of the program into a Java applet for local execution might be best. The optimal choice varies according to the application and the hardware resources available. There's no one best solution.
If a program is written with low-level tools, then the programmer must decide on an approach during development. He can do what's best for his hardware, but the solution is hard-coded, and might not be portable to other clients/networks. But, if the application were developed with a higher-level toolkit, then the optimization to adapt to a different client capabilities and network bandwidth can be done and redone automatically, as much as needed to track changes. (Even if the process isn't automatic, manual reconfiguration of some options is faster than rewriting the whole app)
This is analogous to the argument about programming in assmebly language vs C. Writing a program in assembly for the 8088 could give you better speed than C (assuming you're truely a master coder, or your C compiler is poor). But then when the program is brought to a 386 it will be much slower than a C program recompiled for the new processor, because the relative execution latencies of the opcodes have changed.
Going low-level ("writing to the metal") can give better results for a certain situation, if the implementor is an expert. But high-level techniques allow more flexiblity later, as well as protecting users from the mistakes of inexpert application developers.
You want exactly a "toolkit".
That's pretty much what I said when I started this conversation. This topic is too old for me to reiterate anymore, though. And the discussion of X's quality gets confused when the sides agree neither on the extent (X as a developer's protocol or as a user's platform) nor scope (nearterm practicalities vs longterm goals). I always take the long view and theorize on solutions that in 20 years may give us interfaces resembling those portrayed in contemporary science-fiction films. This may be misinterpreted by someone only interested in code he can deploy next week.
Someday there may be a replacement for "buttons" and "menus" and "icons" that is far more user friendly (no, I don't know what, if I did I would be writing it!) and when that happens the people who wrote toolkits into the system are going to look as stupid
If they used a traditional button/menu/icon toolkit then they'd have some re-writing to do, yes. But everyone uses toolkits like that today, and they'll all have the problem. OTOH, if in the meantime some people develop and code to a higher-level toolkit (where the application programmer doesn't think in terms of "menus" and "icons" but in "commands", "properties" and "relations"), then they might be able to just update the toolkit to the new paradigm.and find the applications automatically working.
arbitrary transformation of an image with error diffusion, something we have known how to do since about 1987 but for some reason is not in any of the graphics systems even today
Really? Apple claims their new onscreen drawing system is all a 2d programmer could ever want. Floating-point coordinates, arbitrary transformation, and antialiasing. You think it's still not good enough?
PS. So I install this Oroboros XDarwin server on a MacOSX system, ssh to a linux box and remote-display some fltk programs, and everything's fine. Then I recompile them on the Mac and run it locally- the picture shows up, and mouseclicks are recognized, but the program can never get focus. So it can never recieve keystrokes.
The gorilla arm syndrome was caused by the combination of touchscreens with boxy, CRT monitors. Now that LCDs can be laid flat on a desk/lap, the strain on your arms will be similar to operating a mouse or pencil.
s/subset/superset
(arbitrary disconnection is just one way to detach)
That post was difficult to read because it uses the X11 definitions of "server" and "client", which are backwards from the usages in VNC, http, UT, and every other client/server GUI framework. That's the reverse of what grandparent had used, but I'll do the X11 defintions below. (Or prehaps viewer/backend would be a more obvious pair of words)
Under the "very high level" approach, the server will just pop up an edit widget here and everything will happen on the server side.
That's just fine.
Now, consider this with the arbitrary disconnect requirement. The wire may be cut at any time,
Where did "arbitrary disconnect" come from? The word I used was "detach", which is a subset of arb-discon. I never implied that a user should be able to just yank out her phone line at any point. To "detach" can require an orderly shut down of the connection (initiated on either side).
Restricting your protocol design to the assumption that the TCP connection can be broken at any time is a mistake, because in normal use such a failure will be rather rare. "Optimize for the common case". Most connections will be terminated by a proper shutdown of the viewer. Of the fraction of connections that break by other means, most will have been after a decent period of user inactivity. Only a surprise hardware failure will cause this kind of instant disconnection.
There's no need to resynchronize after every single edit on the viewer. As you've said, the penalties would be enormous. Waiting 10-30 seconds will be good enough, and it won't break any assumptions users have with operating computers. People today fully accept that if their hardware fails, the editing they've done since the last explicit "save" command will be gone. (If they can get back a portion of the modifications- suitably flagged as "recovered auto-save data"- then they see it as a bonus)
Forbidding unannounced connection-breakage is a small price to pay for maintaining some of that "elegant simplicity".
ECJ is a typo in this case, but it does happen to be a real project (one that I've used for longer than I care to recall)
even faster and snappier, though: TightVNC. With 8-bit mode and compression, it's completely usable and has almost no discernible latency over my cable modem line.
Funny, over my 10mbps ethernet line I use X11 with no apparent latency. But to access MS Windows machines on the same network I've tried VNC (in 3 formats- normal, Tight, and some other name), and it wasn't ever usable. This may be application-specific (Microsoft Word was hopeless)
Let me point out a simple higher-level protocol that's much faster than X11 or VNC: rsh/ssh (or telnet). I'm sure you know that if you're going to run console-based programs, creating a local console and ssh-ing to the host computer will be terribly faster and more responsive than transmitting a remote xterm over ssh -X. That kind of performance advantage is what a well-designed higher-level graphics protocol could eventually give us.
In an even higher level system like picogui, this will be even harder still.
Totally wrong. The only reason detachment was hard for X is because the designers didn't plan for it. In a higher level system, you could not only detach more easily, but with less wasting of resources. There'd be no need to maintain bitmapped images of all your programs when they're not in use- the GUI system can regenerate those when the user next becomes active.
In general, the higher-level an API is, the easier it will be for new features (like detachment or network transparency) to be slipped into the system without breaking existing users. This is getting towards one of the benefits of the "OSes are irrelevant" story, which was similarly hijacked by an inflammatory article-title.
The kind of network-transparency I'd like to see someday includes client-side knowledge of what a pressable-button is and what a scrollbar does. If the client knows that movement of a scrollbar is bound towards the Y offset of a picture in a frame, then as long as the picture has already been buffered, up-down scrolling can be a completely client-side operation. The only data going back to the server is a 16-bit new Y coordinate, and nothing has to come from it at all. (Of course you can get into some complicated management of just how long the client should maintain caches of offscreen images, but the high-level protocl designers can worry about that).
Imagine I'm using a higher-level protocol to run a program on a remote machine and scroll down a long document. The client is keeping a cache of the graphical image of part of the document- not just the section I'm currently viewing, but what I've recently seen, and what I'm about to see. The system could assume that someone looking at page 4 will soon look at page 5, and pre-buffer it so that when I do hit the scrollbar, redraw is instantaneous. No lower-level protocol will ever be able to make that kind of optimization.
A much better idea might be to invest in some cleanup efforts in X11 itself. For instance, the protocol is rather old and is becoming somewhat more crufty with time.
Once you start doing that though, you've no longer got "X11". Eliminate any part of the protocol, and the backwards compatibility that is X11's biggest advantage is gone. You'd be essentially creating a new protocol by reusing X's ideas and code. That would be an even harder sell to the app developer community, because in the end it varies so little from existing X.
to implement the X protocol stream. And once you do that, ta-da you're an X server once again, just like XFree86.
How do the Object-Oriented guys say it? Containing or implementing X is not the same as being X. Microsoft's Windows GDI and Apple's Aqua are "backwards compatible" with X11 in the sense that you can install and run an XServer on top of them. But they're not "an X server again".
current UNIX ports of OpenOffice and Mozilla
Both OpenOffice and Mozilla run on non-X11 GUIs, I think. So some of the work of migrating them to another GUI has already been done. Likewise both the Gtk and Qt toolkits can run without X11. This point isn't insurmountable. (Although, to take proper advantage of newer GUI abstractions you'd have to re-write a lot of code anyway, because the way a user interacts with the application is going to be different).
one of the biggest benefits of X: the X protocol stream and the client/server model. D'oh!
Its a benefit, and also a hinderance. Many people are not served by this client server model. On one side are people who claim that "I'm sitting right at the computer, why should there be a network-protocol abstraction getting in the way of raw performance?". On the other side are those who want network transparency but find that X is too bandwidth intensive to be usable.
Ever try running X11 programs across the modern internet? It's very painful (unless you have some amazingly fat fast pipe). A simple "ls" in a remotely displayed xterm seems to take forever. But yet, gorgeous online games like Counterstrike and Warcraft are fast and snappy. Of course this is because the games are communicating at a much higher level than the X drawing primitives do. With newer, higher-level GUI APIs, more applications might be able to get this kind of benefit. It all depends on where in the application you define the partition between stuff running on the client and the server. PicoGui tries to run more of the GUI parts on the client-side, reducing the bandwidth needed to keep the program going.
(Related historical half-truth: the Java language was originally meant to be platform independent so that the partition between the client/server parts of a program could be determined at runtime, to best match the computing and network hardware on both sides of the link.)
X is not going away.
Not for a long time. It is absolutely true that the biggest advantage to staying with X11 is inertial- the big mass of existing applications. But at some point one will always need to break with the past. Today we can plan where to go, even if the trip isn't practical yet.
I don't disagree with the point you're inexpertly trying to make, but you're doing a terrible job.
No one else was making the point. True, I didn't have time to write much. But a barrage of "X is fine! You just don't understand X" posts had already started, and there was nothing better up to defend the idea of a next-generation GUI.
on Windows you've got OWL and MFC for starters
Does anyone really use OWL anymore? You're sure not going to earn a "Optimized For Windows XP" logo with those kinds of buttons!
you're misunderstanding the scope of X11
The (limited) scope of X11 is the problem.
But you can't argue that X11 needs to be supplanted by GTK.
Like I said, X11 is filling two roles. One role is that of a protocol, and it's fine there. The other role is that of a platform, and that's where it needs to be supplanted. Sure, we'll always have "Freedom of Choice" in that old/alternative source code won't just evaporate. But the only way the user-computer interactive process can become truely better (better than today's X11 desktops, and also the Macintosh and Microsoft offerings) is when someone creates a sufficiently powerful abstraction that application programming and GUI programming can be completely disjoint. And yes, good abstractions are hard, and PicoGui is really just a tentative step along the way, but developers need to explore this terrain if we're ever going to get a better system.
(X11 compatibility can of course be retained as legacy support for a long time)
The proper solution is to make all the higher-level widget sets interoperable. That's a harder problem.
Since PicoGui is not a widget set, one way to approach that problem is to write all widget-sets as PicoGui themes.
Why use gcj? One might assume that compiling to native binaries is faster than using a JVM, but benchmarks don't agree.
My own tests have supported this conclusion. Implementing the same simple algorithim in Sun's Javac/Java, ecj/Java and g++/C++ shows that ecj's code is not only slower than g++'s, but slower than Javac's too. My theory is that java's arithmetic primitives involve additional semantic information (like the possibility of overflow exceptions) which ecj isn't smart enough to optimize away.
GCJ programs tend to use less memory than one in a JVM, but this is an area that future JVMs can improve upon (and in general, once people start using the same VM for multiple java programs, this will get better).
Still, you can see from these comments that the primary picogui.org webpage gives people an impression of Mac-likeness. You might better advertise the project if you have more than one screenshot (with different themes) linked from the front page.
Apparently, people come in, look at the "latest screenshot", and assume its theme applies to everything.
Here we see a common pitfall of debates about the quality of X- an overloaded word. "X11R6" strictly means just a low level drawing protocol. But, in the absence of anything better, it is also means the GUI system that runs ontop of that protocol.
This same problem happens in discussions about Linux. The strict definition is an OS kernel, but "Linux" has also come to be a blanket term for the whole family of Open Source operating systems that use that kernel. "Operating System based on the Linux kernel" is too long to use in everyday speech, so it gets abbreviated down to "Linux". ("GNU/Linux" is also too long, apparently)
So then, when someone attacks Linux (the broad definition), defenders can point to the specific definiton and dismiss the complainer on the basis that he's uninformed. When this happens, the debate is cut short, without a fruitful discussion of the merits of the problem.
Back to your point. You mention that for Apple's Aqua and Microsoft's GUI there are corresponding lower level APIs: DPS and GDI respectively. But this raises the question: What higher-level system corresponds to X11R6?
There isn't one. Or there's much more than one (Xt, Athena, Motif, Qt, Gtk, XUL, Fltk, WxWindows, TK...). Neither of those answers is useful as a starting point of discussing new GUI enhancements. You can pick any one of those toolkits and consider improving it, but then you're just addressing a fraction of all users (although maybe hoping that your favorite toolkit will rise to dominance above the others).
GDI and DPS are each found inside of one and only one GUI framework (architexturally a stack of blocks, instead of the branching tree of stuff that builds on X11R6). That's a consequence of monolithic developement instead of open systems, but it makes many things simpler on the users. How do you resize a window in Microsoft Windows? The answer is straightforward. How do you close a program in MacOS X? Another simple answer.
Neither of those operations is defined for X.
Only application developers are ever aware that DPS and GDI exist- they're completely hidden under the GUI. But users of X11R6 are frequently reminded of its presence. "Why isn't your program working? Did you check the DISPLAY variable? How about the xhosts? Ok, lets look at the MIT Magic Cookie..."
The world of Unix-like software can never have really great GUIs until X is invisible to average users. Maybe this means X has been supplanted by another system, or that it's just been relgated to the status of a device driver.
It's true that the competitor to PicoGui isn't X, but higher-level protocols. However the headline "An X Alternative" is not incorrect. Someday X's position as the premire "Unix GUI Application Development Platform" will be supplanted by something like Gtk, Fresco, or PicoGui. Then developers will begin to release software which runs on $NEW_DISPLAY_LAYER, rather than X directly. (Even though $NEW_DISPLAY_LAYER might still use X11R6 as a backend)
Someday a better UI environment will come around, when the only program allowed to connect to my X server is a single process from $NEW_DISPLAY_LAYER. It will enforce on applications the appearance and behavior that I want them to have, rather than leaving it up to individual authors.
Because until the late 90's desktop UNIX renaissance
The late 90's means 1997 or so. It's 2003 now, that's 6 years. And it'll surely be at least another year before RnR becomes broadly available. That's a long time. (Especially when you consider that the RnR guys only needed a few months, once they started. This suggests that writing extensions is so hard that only a select few can do it. Not encouraging)
Apple and Microsoft have both improved their GUIs enormously since 1997. X (and the other Unix graphics system, OpenGl) don't seem to have gotten much better during that time.
Since the founding of the XFree86 foundation, X has been improving at a faster rate than it has in fifteen years
XFree86 was founded in 1994. I guess I don't remember how well X worked in 1979, so I can't comment on how fast it's progressed.
Are we not changing resolutions when you "ctrl, alt, keypad +|-??????
No. Ok, maybe the monitor changes resolutions. Your desktop and all applications aren't aware of any change (like they would be in MS Windows for instance). Once you press Alt+/- in Xfree86 your entire UI experient is degraded by the constant need to shove around the viewport with the mouse cursor.
That feature is worthless for anything but a quick zoom-in on an image, or for testing refresh-rate configurations.
The 8 years it took for X to get the RnR extension is an example of why so many say "X is Bad". If the extensibility is so great, then why did such an obvious improvement take so long?
(Counting from when Microsoft first introduced that feature, and including the fact that end-user desktops don't have RnR yet)
As always, what you should use depends on your needs. If X works perfectly for you, then great. As a "frame-buffer oriented network-transparent graphics API" it'd be hard to beat. As the foundation for kits like Gtk and Qt (and even PicoGui sometimes) it works well.
However, as a platform (a standard for application creation) X is sub-optimal for users and developers.
The value of a standard comes not only from what it allows you to do, but what it forbids.
Suppose I write 3 programs to perform the same tasks under different GUIs: Microsoft's, Apple's OS X Quartz/Aqua, and X11R6. A Mac user can sit down without looking at the instructions and use his familiar old mouse motions, menu commands, and keystrokes with hardly a glance at the new stuff. A Windows(tm) user has nearly the same advantages. The icons for the same feature (Save, Print) look exactly the same, regardless of the program.
Of course that's not the case for X programs. Whenever I sit down at a new X11 program, I have to spend a few minutes recalibrating the basics ("How to I copy/paste, again?")
Because X allows the developer so much freedom, it deprives the user of the ability to anticipate how a program will operate. "The program can do nearly anything" sounds like an advantage, until you try to predict what a program will actually do!
Note that a weakness of Apple and Microsoft's GUI systems is that the "forbidding" part of their standard often comes in the form of "law" instead of "code". The taboos are enforced by developers getting chastised by the GUI vendor or the public when a non-ituitive program is released.
A weak method- the lag time for feedback is long, and if the offending developer works for the GUI vendor, he might insert loopholes into the rules.). But it produces superior results to X programs, where the users lack an imposing rulebook to point to as formal justification for their complaints. Improvements may happen, but there's nothing forcing them to converge on one way of doing things.
Some common responses to this argument:
"You want a toolkit, not X"
Maybe so. If a user's desktop could only run one toolkit, she'd never see an unfamiliar interface. This has the problem of discarding pre-existing programs, but argument-by-popularity is a logical fallacy (I'm talking about what solution would be best, not cheapest short-term). Better than using a single toolkit, though, is somehow allowing the application to be written independent of toolkit, and obeying whatever HCI conventions a particular user enjoys. PicoGui tries to do this.
"No one can be sure what the best interface is. Keeping flexibility gives us power."
In theory it does, but at the expense of accessibility. Too often it means that developers who don't want to be "HCI Researchers" find themselves wrestling with UI code that's entangled their applications.
PicoGui (and other "next-generation" UI systems) attempt to resolve this by keeping the application programmer further from the UI code than is traditional. (They haven't been totally successful yet)
He can't mess with the per-pixel alignment of buttons, because that's outside of the application's control.
This is fundamentally better than the way Apple and Microsoft's traditional Human Interface manuals have worked, because enforcement of the rules is done not by humans (punishing programs that act wrongly) but by software (doing the work for you, so it's guaranteed to do it right).
You're being far too specific here. An "engineering license" is only needed in certain jurisdictions and for certain jobs. Maybe this is true where you live, but don't assume it applies to everyone.
Many people use the word "engineer" to cover many more kinds of jobs than it really means (The strictest definition is someone who maintains an internal-combustion engine. The broad definition is someone who makes "science and math useful", which can mean anyone). So before making statements about what "engineers" have to do, its best to specify just what you mean.
Um, in the jargon of special effects, "motion controlled" means that the motion of a camera or its target (or probably both) is controlled by a computer. It's a way of filming miniature models.
Computer-generated imagery doesn't count, as there's no actual motion. Special Effects experts consider this a real difference.
You could argue that "virtual motion-control" has been performed, but that's a big stretch. The difficult part of motion control is mechanical engineering- working 100% in software lets you trivially increase the entity count by doubling your filesize + rendering time. (I could argue that I beat the world high-jump record when I played Virtua Fighter 3, too)
The Star Wars motion control record will probably stand forever, since big use of motion control is no longer cost effective to pursue.
That was a decent series- but not as good as Picket Fences. Now that's something that deserves some DVDs. The creator, David Kelley, has been TV's golden boy for the past few years. I wonder why they've never tried to put out his old stuff.
However, sci-fi/fantasy in general will have a better audience for DVD publication than a show in the "real world". Maybe not bigger, but more dedicated. A particular fan can be roped in not just by characters and story, but by technology (setting, props, costume, makeup). For nerdy folks, the opportunity to speculate on the plausibility of imaginary technology can be a big draw.
(Coincidentally, nerds are more likely to collect DVDs)
POSIX aren't OSS creations etiher
This isn't what you mean, but "POSIX" is technically an OSS creation- that word was invented by RMS.
Of course neither his GNU nor Linux ever managed to implement POSIX, and POSIX can't be called an innovation anyhow. Its a standard, a codification of existing practice- nothing new.
Try again with some constructive criticism, not just criticism.
For most of these problems, there's no easy way to really fix the abstraction. The only solution is for users to be aware of the abstractions they depend on, so that they can troubleshoot the underlying foundations if things break down.
The article is constructive in that it spreads a warning to be cautious about relying on abstractions too much, without understanding how they work.
Over time processor performance buries these penalties.
Sometimes. But not all penalties can be resolved by more CPU cycles. A faster CPU can't repair your severed ethernet wire. It can't change all the existing HTML browsers and C++ compilers to cover up supposed "flaws".
And unless this CPU is awesome enough to enable real AI, it can't save us from future shortcomings in computer-interface languages either.