If its not good (i.e. free) enough for GNU people then that is their problem. I would point out that the level of free'ness is more crucial at the foundation/library/OS level than further up.
Furthermore, if the non-GPL'd ness of this product actively encourages development of a potential killer product for free platforms then that is all the better.
The question that should sit in GPL people's mind is what would happen if development would slow down or cease, so that commercial support is no longer possible.
In -that- case there would be a strong argument for a GPL style release, but in its current state I see no problem. John
They've tried to marry the look of GNOME to the feel of PalmOS, with a little extra glitz. They have not said 'we must have GNOME style menu bars and GNOME style dialog boxes' which is the mistake of CE.
In fact I personally would rather take their results as a starting point for designing a desktop UI, since their design philosophy seems to be to begin with the user experience and construct everything with that in mind, rather than the 'feature/eyecandy shopping list' that is so prevalant with many GNOME and KDE apps.
When it and PDA's for it are available, they will have plenty of extra capacity to handle it. John
"The concept of an operating system has been dying for quite a long time.
When he says that the concept of an OS is dying, he means that interest in the how and why of an OS is dwindling, and eventually won't be able to support the development. Consumers like applications and don't care about the OS. Content providers deliver content and don't care about the OS, so long as the money keeps rolling in. etc. etc. The proportion of the industry with any vested interest in operating systems is small and getting smaller. Remove M$ from the equation and it should be clear where this guy's coming from. The paper about the lack of innovation and work on operating systems research is another feather in the same bow --- the concept of the OS is an important, but increasingly neglected one. That is the problem, and the Amiga person's comment is that more OS's won't fix the problem.
A critical problem with editing TeX, for which realistic solutions are only now arriving, is that it is difficult to track the implications if various macro definitions and font definitions.
It is very difficult to have a setup with real time feedback as to changes you make to a TeX document.
Furthermore, it is even harder to write an editor for TeX that allows you to use the extensibility without the possibility of breaking the document (i.e. the TeX file the editor spouts needn't be able to fit through a TeX compiler)
The strict structure enforcement possible with XML together with the possibility of database backends makes for a far brighter future. (p.s. suppose you want to search through a bunch of TeX documents and extract all definitions, say. The ability to do this at all requires discipline from the document author, and so realistically limits itself to a single author set-up or a closely knit group. (SG/X)ML with DTD's doesn't suffer the same fate, and can still use a TeX formatter as the backend.)
I'll end with a quick point, very worthy of note.
TeX is for typesetting, not wordprocessing and general document production. It is only the clever design and extensibility of TeX that makes it even suitable for such tasks.
The copyright holders are under no obligation to enfoce the GPL. Seriously, which of the Doom software authors is going to sue?
The GPL in this respect tends to be used the way that large corporations use patants. Basically, everyone treads on everyone else's feet, and if one calls in the lawyers, so do all the others. Think about the situation rather than just stating what the text says. Also bear in mind that the in-court strength of the GPL has yet to be properly tested. John
Last time I tried KWord, there was no obvious way of putting equations in the text. It was possible, though barely, to put an 'equation frame' in, but it could not automatically scale with the size of the equation and nor could it move with the text. I gave up after that. John
The real memory hog is the window manager - go back to slim WM's like twm or fvwm and you'l be surprised how much you can do with very little CPU and memory. If you want something piggish like GNOME or even KDE, though, all bets are off, but that's NOT the fault of X! X is not just the X server. The fact that anything more than a basic UI is impossible is not the fault of people trying to write them. Consider that the RISCOS GUI on the Acorn's had to fit everything in 2Mb, including applications and data, and with no VM. Similarly, consider what NeXT got out of their cubes. The fact is that the overheads induced by an X server make beautiful simplicity an impossibility. John
Re:Common misconception over XFree memory usage
on
Berlin 0.2.0 Released
·
· Score: 1
The memory requirements that X apps tend to place on the system has been with X through most of its years in the field. It's not a problem that has been solved effectively, and most likely will remain that way.
This should be considered a fault in the basic design of X. John
Between the work of Next (on NextStep), IBM (on OS/2 WPS) and even M$ (with Win2K and COM). It has been reasonably well shown that middleware centric UI's can be done efficiently, can be fast, and can be easy to program.
If CORBA doesn't work out, most of the work and, more importantly, most of the thinking and design, can be refactored around a different middleware architecture.
The feature bloat of CORBA together with its 'least common denominator' approach make it suitable to experiment and see what parts of a middleware centric ui architecture are the important ones.
But for everyone's sake, don't jump on the bandwagon for the sake of it. It's important for them not to have to do things urgently -- that's where braindamaged designs tend to come from:-) John
ReiserFS may be pretty cool stuff, but it hasn't led to really new things. There is the offer that it may allow constructing data structures reasonably efficiently via "hordes of tiny files," but nobody is really using that yet, and the "research" side of that is already reasonably well-understood.
The interesting part of ReiserFS is yet to come. The current FS is the foundation for it. Read around namesys' site to see...
As for CORBA, the idea of language independance is an oxymoron. Basically they require huge amounts of binding code to connect to huge amounts of middleware code to connect to other huge amounts of binding code. Where has the idea of compactness and beautiful simplicity gone?? John
People who care need to take heed of this. There is no immediate gain from innovation.
The current status quo is stagnant -- that is his point. It takes the people who do interesting things, not because of possible gains, or possible 'success', but because they want to.
That is the attitude that produces the most diverse thinkers, because requirements to 'attain success' do not constrain them.
That is the attitude that the author of the article claims that we need. I completely agree. John
The point of the architecture is not that you can add new custom chips, custom instructions, etc. and utilise them.
The point is that Tao makes it easy to do so (recall how long it took for MMX to catch on and get used... with this, you update the VM/compiler thing and you're virtually done). John
Important consideration needs to be given to the conflicts between pixel accurate rendering and device independent rendering. The latter IMO should be the default, since most often you are concerned with accurately drawing an image on the screen (accurate from the point of view of the person using the system rather than the framebuffer). John
For the same reason that someone doesn't write an extension to remove the cruft that's already there. Moral: design first, code later, redesign, code again, rinse, lather, repeat, etc. stop when the design is properly done, properly documented and you KNOW what your software is supposed to do, why it does it, and where its usefulness ends. John
Turing completeness is meaningless in the case of a display architecture. For example try writing a windowing interface in TeX (which, alas, is also Turing complete). John
Look at both Windows (GDI) and the old Postscript based systems. In fact look at the new system deployed in MacOS X.
What you notice is that the screen rendering system is integrated with the printing system so that, at least in Windows langauge, the printer is 'simply another device context to write to'.
It is crucial that the printing of documents, image, etc. to a hardcopy device is not left as an afterthought as it was with X. It should be simple for an application to say `print these to such-and-such a printer'. This requires that an X server have knowledge of other output devices besides itself, but this is not so stupid an idea. (The idea of X as a dumb display device should be consigned to its rightful place in the nearest dustbin). John
On the other hand, what we do NOT need is four new tools written in different languages -- then you'd have to learn up to 4 languages if you wanted to fix/modify the tools.
Whilst they could have left the detail of the implementation language till later (allowing for other languages such as PERL), it would make things more difficult at a later stage to decide on one language and mandate that for the implementations of all the winning designs.
So far as the XUnit suggestion, who would want to write an implementation of all the tools in every language?? John
As some support to the presence of an autoconf problem
How may times has configure failed, giving some error message but no further explanation and no information dumped to config.log?
Who decides what is and isn't a valid architecture description (i.e. i386-pc-linux-gnu works with some configures, not with others, i586-pc-linux-gnu works with even less)
Running autoconf... if it drops out with an error saying `fatal bug, contact the authors', how does this help me compile the program??
Running autoconf, autoheader, automake, libtoolize, auotgen.sh, etc. Why so many programs? Why are they in different languages, why do they seem to end up second guessing each other?
Things need to be changed to the effect that you don't get a huge bourne script with the tarball that may or may not work, and for which configure.in can't be fixed or used to construct a new configure program since your.m4 files don't sync with the author's. John
Slashdot Mirror
If its not good (i.e. free) enough for GNU people then that is their problem. I would point out that the level of free'ness is more crucial at the foundation/library/OS level than further up.
Furthermore, if the non-GPL'd ness of this product actively encourages development of a potential killer product for free platforms then that is all the better.
The question that should sit in GPL people's mind is what would happen if development would slow down or cease, so that commercial support is no longer possible.
In -that- case there would be a strong argument for a GPL style release, but in its current state I see no problem.
John
With Windows 95, Microsoft designed it to be useable on current (486-33'ish) hardware, but sadly went downhill from there.
John
They've tried to marry the look of GNOME to the feel of PalmOS, with a little extra glitz. They have not said 'we must have GNOME style menu bars and GNOME style dialog boxes' which is the mistake of CE.
In fact I personally would rather take their results as a starting point for designing a desktop UI, since their design philosophy seems to be to begin with the user experience and construct everything with that in mind, rather than the 'feature/eyecandy shopping list' that is so prevalant with many GNOME and KDE apps.
When it and PDA's for it are available, they will have plenty of extra capacity to handle it.
John
low power consumption?
portability?
stop equating 'computer' with 'desktop PC' for a moment.
John
John
It is very difficult to have a setup with real time feedback as to changes you make to a TeX document.
Furthermore, it is even harder to write an editor for TeX that allows you to use the extensibility without the possibility of breaking the document (i.e. the TeX file the editor spouts needn't be able to fit through a TeX compiler)
The strict structure enforcement possible with XML together with the possibility of database backends makes for a far brighter future. (p.s. suppose you want to search through a bunch of TeX documents and extract all definitions, say. The ability to do this at all requires discipline from the document author, and so realistically limits itself to a single author set-up or a closely knit group. (SG/X)ML with DTD's doesn't suffer the same fate, and can still use a TeX formatter as the backend.)
I'll end with a quick point, very worthy of note.
John
The copyright holders are under no obligation to enfoce the GPL. Seriously, which of the Doom software authors is going to sue?
The GPL in this respect tends to be used the way that large corporations use patants. Basically, everyone treads on everyone else's feet, and if one calls in the lawyers, so do all the others. Think about the situation rather than just stating what the text says. Also bear in mind that the in-court strength of the GPL has yet to be properly tested.
John
So just how does 'redundant' figure in that??
Redundancy means that more data is written than necessary in order that the original data can be recovered in the case of an error.
John
Last time I tried KWord, there was no obvious way of putting equations in the text. It was possible, though barely, to put an 'equation frame' in, but it could not automatically scale with the size of the equation and nor could it move with the text. I gave up after that.
John
The real memory hog is the window manager - go back to slim WM's like twm or fvwm and you'l be surprised how much you can do with very little CPU and memory. If you want something piggish like GNOME or even KDE, though, all bets are off, but that's NOT the fault of X! X is not just the X server. The fact that anything more than a basic UI is impossible is not the fault of people trying to write them. Consider that the RISCOS GUI on the Acorn's had to fit everything in 2Mb, including applications and data, and with no VM. Similarly, consider what NeXT got out of their cubes. The fact is that the overheads induced by an X server make beautiful simplicity an impossibility.
John
The memory requirements that X apps tend to place on the system has been with X through most of its years in the field. It's not a problem that has been solved effectively, and most likely will remain that way.
This should be considered a fault in the basic design of X.
John
Between the work of Next (on NextStep), IBM (on OS/2 WPS) and even M$ (with Win2K and COM). It has been reasonably well shown that middleware centric UI's can be done efficiently, can be fast, and can be easy to program.
:-)
If CORBA doesn't work out, most of the work and, more importantly, most of the thinking and design, can be refactored around a different middleware architecture.
The feature bloat of CORBA together with its 'least common denominator' approach make it suitable to experiment and see what parts of a middleware centric ui architecture are the important ones.
But for everyone's sake, don't jump on the bandwagon for the sake of it. It's important for them not to have to do things urgently -- that's where braindamaged designs tend to come from
John
As for CORBA, the idea of language independance is an oxymoron. Basically they require huge amounts of binding code to connect to huge amounts of middleware code to connect to other huge amounts of binding code. Where has the idea of compactness and beautiful simplicity gone??
John
i.e. people act like the field is complete when, in truth, it couldn't be further.
John
People who care need to take heed of this. There is no immediate gain from innovation.
The current status quo is stagnant -- that is his point. It takes the people who do interesting things, not because of possible gains, or possible 'success', but because they want to.
That is the attitude that produces the most diverse thinkers, because requirements to 'attain success' do not constrain them.
That is the attitude that the author of the article claims that we need. I completely agree.
John
The point of the architecture is not that you can add new custom chips, custom instructions, etc. and utilise them.
The point is that Tao makes it easy to do so (recall how long it took for MMX to catch on and get used... with this, you update the VM/compiler thing and you're virtually done).
John
General rule of thumb: when language conventions are defined, stick with them.
In any case, the name 'functional' comes from the fact that the language is built around the evaluation of functions (in the maths sense, i.e. defining "functional" as useful basically means that you have to find a new, more convoluted name such as "function-evaluational langauge".
John
Compactness -- for people who have to move around, there's something to be said for a combined CD player, DVD player, Computer, TV, Video, etc.
John
Important consideration needs to be given to the conflicts between pixel accurate rendering and device independent rendering. The latter IMO should be the default, since most often you are concerned with accurately drawing an image on the screen (accurate from the point of view of the person using the system rather than the framebuffer).
John
Including a printing API that is part of the display architecture...
John
For the same reason that someone doesn't write an extension to remove the cruft that's already there. Moral: design first, code later, redesign, code again, rinse, lather, repeat, etc. stop when the design is properly done, properly documented and you KNOW what your software is supposed to do, why it does it, and where its usefulness ends.
John
Turing completeness is meaningless in the case of a display architecture. For example try writing a windowing interface in TeX (which, alas, is also Turing complete).
John
Look at both Windows (GDI) and the old Postscript based systems. In fact look at the new system deployed in MacOS X.
What you notice is that the screen rendering system is integrated with the printing system so that, at least in Windows langauge, the printer is 'simply another device context to write to'.
It is crucial that the printing of documents, image, etc. to a hardcopy device is not left as an afterthought as it was with X. It should be simple for an application to say `print these to such-and-such a printer'. This requires that an X server have knowledge of other output devices besides itself, but this is not so stupid an idea. (The idea of X as a dumb display device should be consigned to its rightful place in the nearest dustbin).
John
On the other hand, what we do NOT need is four new tools written in different languages -- then you'd have to learn up to 4 languages if you wanted to fix/modify the tools.
Whilst they could have left the detail of the implementation language till later (allowing for other languages such as PERL), it would make things more difficult at a later stage to decide on one language and mandate that for the implementations of all the winning designs.
So far as the XUnit suggestion, who would want to write an implementation of all the tools in every language??
John
- How may times has configure failed, giving some error message but no further explanation and no information dumped to config.log?
- Who decides what is and isn't a valid architecture description (i.e. i386-pc-linux-gnu works with some configures, not with others, i586-pc-linux-gnu works with even less)
- Running autoconf... if it drops out with an error saying `fatal bug, contact the authors', how does this help me compile the program??
- Running autoconf, autoheader, automake, libtoolize, auotgen.sh, etc. Why so many programs? Why are they in different languages, why do they seem to end up second guessing each other?
Things need to be changed to the effect that you don't get a huge bourne script with the tarball that may or may not work, and for which configure.in can't be fixed or used to construct a new configure program since yourJohn