By that count, if you have 37 million samples, the propability equals 1 eventually, and with 74 million, it approaches 2!! The moral of this being that you can't just multiply.
The rule you are mistakenly using is
P(A or B) = P(A) + P(B)
this only happens if A and B are mutually exclusive, which brings with it that 37m samples will guarantee a match. In general, the formula is
P(A or B) = P(A) + P(B) - P(A and B)
BTW, the 1/56 figure is the probability that you have the right person given only the match in the DNA. John
Programs that DEPEND on libc need some of the libc symbols. Ideally, there would be a normal and debug version of libc, together with the source, such that when you debug, gdb always knows where to go. That said, its easier said than done (since there's no protocol to adhere to when writing a debugger such that you can select the libraries that ld.so should link with) John
(Hypothetically speaking), since you have the imaging architecture in place for printing the file, why not just use that to obtain a WYSIWYYG display??
(This is what NeXT and anything DPS driven was able to do, and what, for similar reasons, the new MacOS X is able to do -- there is a single imaging model that is powerful enough for handling both dislplay and printing. X11 just doesn't cut it in this respect (drawing support that is on par with Windows 2, no useable scalable font support...) John
With an RPM file, you can see where its going to go, but virtually all RPM's can't be relocated. If you wan't the RPM to be installed elsewhere, you need to exract and install the files manually. John
It's an obvious point to make, but why do we still have main() actually parsing its arguments? Surely it is the job of the runtime to do this (and then pass main() an array of options) John
Furthermore, if you have two applications running on different hosts, you need to have an identical copy of the theme engine on each host, and some way of telling the GTK application which theme to use (.gtkrc obviously doesn't work since it is bound to the host on which the application runs (and I consider using NIS home directories to do this to be a kludge)) John
Simply the ability to arbitrarily redirect the display isn't a sufficiently good reason to keep X. You can do the same reasonably well using DPS on the display side, and with that you get a decent imaging model to work with.
Themability is a good idea. It's just that you can't really do it well with X, since user interface consistency isn't enforced at all, and the themes are essentially bound to the host on which the programs are running, not the display to which they are displaying. John
It can't match anything much on 'user apparent' speed grounds -- X's event model takes care of that.
It isn't extensible, regardless of what everyone else says -- for examle GLX was around donkeys' years ago, but no-one's able to 'extend' XF86 with it until now (you can't extend X at run time, you've gotta hope you've got the source to extend it at compile time, and then you've gotta make it work with your X server)
Its , network transparency was done better by QNX with their MicroGUI (which based its protocol around distributed IPC). Even NeXT could just redirect object commands and postscript display commands -- X didn't have the display model to keep up.
p.s. C has good programs written for it quite often -- X doesn't have good UI's made with it. John
I may be being stupid here, but how exactly does one specify a default geometry or default font that depends upon the size and resolution of the target display?
How does one specify colour defualts etc. such that if you have a 256 colour display, it doesn't hog the colour maps?? This should be a trivial affair for a display architecture that was 'designed from the ground up to be network transparent'.
I'm afraid that the limitations such as the above come from X's origins as a black and white, pixel based protocol for allocating rectangles on a screen -- all else is (and appears to be) an afterthought. John
I don't know about KDE 2, but to make the point clear, Drag and Drop should be TRIVIAL to add to a program (you should just 'declare the GUI object as draggable' and the UI logic should do the rest) John
You could just say 'prouced'. The basic point is the same -- RAD. Application developers shouldn't have to do intricate component development (i.e. going through code with a fine toothcomb, removing wasted instructions etc.). When was the last time you heard someone complain that 'mending a car' wasn't really mending since 'you don't have to do all the complicated bits'). John
KDE and GNOME are good steps in the right direction.
Sorry, but the first step to consistency HAS to be dropping X. The various UI components that everybody uses 101 and more UI toolkits to generate need to reside in the display, as does most of the UI. Only the non-trivial aspects of the application should even need to be handled by the application's code (the only library it should need to link to is the one which allows it to communicate with the display server (-lc and -lm excepted of course)).
I don't think GNUStep/OpenStep/NeXTStep whatever is really going to ever be any sort of standard, IMHO. Nice interface, nice technology, but too far from mainstream interfaces.
The only thing currently mainstream that stands any chance of being a standard s Windows. This has been reiterated time and time again. If you believe in what you stated above, you should really be working with the WINE people, whose task is to implement the most mainstream of application interfaces. John
For example, when proving a major theorem in some research paper, you'll write some smaller things building up to your main result(s) in 'lemmas'.
What the previous poster is referring to is sets of 'when this holds, so does this' type implications (e.g. if a is invariant bc and ca, we know that ba and don't need to work this out explicity) John
True, but languages that punish bad code, rather than just accept it will have better (and usually less -- another improvement) code written for them.
Consider what would happen if you recieved a 40V electric shock every time you wrote bad code, or were in careless in some way -- there'd be less coders writing code, but the end result would be better (provided that the electric shocks were dealt out fairly -- and this is the problem of standardising...) John
The point is being able to write 10x quicker, and have everything run within x% of the original.
This is an important point in practice -- do you want to spend ten times more in order to get something 5% faster? The idea of microkernels, abstraction layers, etc. is to make other peoples lives easier, whilst still being fast enough.
The major difference in the compile/run cycles will be that there is no (this is source, this is intermediate, this is compiled) dividing lines -- anything goes:-) John
Dont be so sure. Compilers typically generate static (i.e. unchanging) code. At best this can be statically optimal for a given task.
However it has been demonstrated (I think that some people at MIT have done this, among others), that statically optimal code is not necessarily the fasted, and dynamic optimisation can increase speed further. (The compiler DOESN'T know what the JIT can find out during runtime, and no amount of minutes spent sitting and thinking can change that) John
The why are the fastest numerical libraries the hand-coded ones? answer: The people doing the coding know things that the computer couldn't possibly. Current languages don's have the structure/semantics/etc. required to convey various mathematical know-how required to clever optimisations (how many compilers will recognise an operation similar to a discrete Fourier Transform and put an FFT in place -- you should note that large number multiplication usually uses such tricks) John
Nope -- the JIT compiler compiles each.class file into native machine code each time the.class is loaded afresh. Further, it may (at its option) recompile the methods of the.class using different parameters (found by profiling). John
While my friend and I read the article, we both thought the same thing: GNOME (and to a lesser extent KDE) are both flexible enough to allow you to create a desktop with most of the ideas that the author had about the perfect desktop.
Consistency? If the two gnome applicatons run on different hosts, what decides the appearance? (and how is it made uniform across the two applications?). GNOME doesn't do this at present, and the CORBA system won't help, since it isn't possible to move binaries across incompatible processors (i.e. you cannot just copy any style files needed from one machine to the other, and the screen-end of the UI (aka X) is powerless to help since all it knows about are the rectangles)
For instance, you could put any gnome-panel on any of the sides of the screen and have any buttons or taskbars or menus or documents or anything on them you darn well please. You could make them any size, and have them autohide at any speed.
content -- How, for example, can you have one of the bars correspond to open applications (i.e. GIMP, netscape, etc.) and another to open documents? you must remember that the GUI upon which the panel rests knows virtually nothing about what is on the screen.
With both QT and GTK, I know that you can "rip" toolbars out of their default position and move them into a vertical position on the right or left, just as the author suggested.
At present only possible at a per-window level. How do I put the 'main toolbar' for the 'currently focused document' on the left (such that it updates as I focus a different document)? How do I put the menu for the current application at the top of the screen? How do I add some global options to the menus?
As far as the round menus go, I just don't know what he was talking about.
Also known as 'Pie menus' think of a circle appearing at where the mouse was clicked, subdivided like a pie chart, such that you, say, go left for formatting details, right for copy.
But, with differnt themes of the respective toolkit, one cold put thick borders on buttons.
Thats eye-candy, nothing more. You can't change the feel or logical arrangement of a GNOME or KDE application with the theme alone.
In short, I agree with you as far as UI designers knowing UI and learning about it. That's obvious, it could always help. But I feel that the inherent flexibility that GNOME and KDE provide go a long way to making the UI usable,
Pardon?? (All I've ended up using is Sawmill, wterm and Xemacs.) There is NO global scriptability for GNOME applications, and similarly for KDE in 1.x. KDE 2.x may be different, I hope so. There is little flexibility at the application level (like you get with various Windows applications -- GNOME and KDE applications aren't mature/bloated enough for that, and wouldn't get sufficient development anyhow)
no matter what you preferences or prejudices or habits or preconcievied notions of what a UI should be.
If your preferences or prejudices relate to simplicity of design, overall thought of design, plans for future, etc. then I'm afraid that that just isn't the case. what needs to be stressed, and isn't is Flexibility, Reuseability, possiblities for Customisation/Integration at the component level -- currently KDE 1.x and GNOME 1.x have no real concept of a component level.
While GNOME and KDE can be improved (what can't be improved?), they also deserve a high-five for their work so far.
True, but it is all too often that the people in charge see the cosmetic factors in their competition, and go all out to emulate those and only those without the thought that has gone in to the rest of the design of what they aspire to copy. The moral of this story is: Think, Think and Think again before you code something that you want to put out (TAI -- Linus didn't think about global users when starting Linux, and didn't distribute it until it was going somewhere, and he's stuck to his aims ever since.) John
So much can be attributed to X There are so many interesting, intuitive ideas as to UI design that can be easily stated, but no-one has a clue how to actually implement in X (let alone simply, efficiently,properly,etc.)
One of the most disappointing things I find with UI design in Linux in general, is that it has so much potential to be better, yet this is not used.
Given that X allows for rectangles to be allocated and a little rudimentry communication between them, it is suprising that people have got so far as they have. Then there are the 'but X is a standard' people that insist that X should be that center of the UI. They can, in a number of cases, appear to back this up by showing that a given feature can be done with X. But what is basically impossible (see what KDE/GNOME are doing to try and manage this) is integration -- when the centre of the UI management has no concept of applications, documents, menus and cannot be told about them.
Even though KDE etc. is appealing to newbies it still remains 'by hackers, for hackers'. In most situations, if Linux developers aren't sure of what they should be doing in terms of UI design, they copy Microsoft.
Too true. What is lacking is documentation of decisions relating to the design, justification of those decisions, and discussions of alternatives, and why not them. The discipline alone in doing this would go a long way to improving design (and would probably resunt in X being dropped a whole lot quicker)
The open source development model of KDE/Gnome allows for some *real* innovation to take place on the UI front, yet it is being neglected. Look at most WMs, and count how many of them use taskbars, or start menu-ish controls. I don't think we can count on MS or Apple to break out of the mind set that "this is what a GUI looks like". Of course to attract users UIs have to be intuitive and natural to use for people experienced with win/mac UIs, but that can not be used as an excuse to halt UI development at the stage it is now.
What is needed is for it to be easier by a long way to make simple changes that are extended over the UI, or ove the system (given the relevant permissions) such that differences can be experimented with easily. John
Slashdot Mirror
The rule you are mistakenly using is this only happens if A and B are mutually exclusive, which brings with it that 37m samples will guarantee a match. In general, the formula is
BTW, the 1/56 figure is the probability that you have the right person given only the match in the DNA.
John
Programs that DEPEND on libc need some of the libc symbols. Ideally, there would be a normal and debug version of libc, together with the source, such that when you debug, gdb always knows where to go. That said, its easier said than done (since there's no protocol to adhere to when writing a debugger such that you can select the libraries that ld.so should link with)
John
(Hypothetically speaking), since you have the imaging architecture in place for printing the file, why not just use that to obtain a WYSIWYYG display??
(This is what NeXT and anything DPS driven was able to do, and what, for similar reasons, the new MacOS X is able to do -- there is a single imaging model that is powerful enough for handling both dislplay and printing. X11 just doesn't cut it in this respect (drawing support that is on par with Windows 2, no useable scalable font support...)
John
With an RPM file, you can see where its going to go, but virtually all RPM's can't be relocated. If you wan't the RPM to be installed elsewhere, you need to exract and install the files manually.
John
It's an obvious point to make, but why do we still have main() actually parsing its arguments? Surely it is the job of the runtime to do this (and then pass main() an array of options)
John
Furthermore, if you have two applications running on different hosts, you need to have an identical copy of the theme engine on each host, and some way of telling the GTK application which theme to use (.gtkrc obviously doesn't work since it is bound to the host on which the application runs (and I consider using NIS home directories to do this to be a kludge))
John
Simply the ability to arbitrarily redirect the display isn't a sufficiently good reason to keep X. You can do the same reasonably well using DPS on the display side, and with that you get a decent imaging model to work with.
Themability is a good idea. It's just that you can't really do it well with X, since user interface consistency isn't enforced at all, and the themes are essentially bound to the host on which the programs are running, not the display to which they are displaying.
John
X as a tool for creating user interfaces is foul
It can't match anything much on 'user apparent' speed grounds -- X's event model takes care of that.
It isn't extensible, regardless of what everyone else says -- for examle GLX was around donkeys' years ago, but no-one's able to 'extend' XF86 with it until now (you can't extend X at run time, you've gotta hope you've got the source to extend it at compile time, and then you've gotta make it work with your X server)
Its , network transparency was done better by QNX with their MicroGUI (which based its protocol around distributed IPC). Even NeXT could just redirect object commands and postscript display commands -- X didn't have the display model to keep up.
p.s. C has good programs written for it quite often -- X doesn't have good UI's made with it.
John
I may be being stupid here, but how exactly does one specify a default geometry or default font that depends upon the size and resolution of the target display?
How does one specify colour defualts etc. such that if you have a 256 colour display, it doesn't hog the colour maps?? This should be a trivial affair for a display architecture that was 'designed from the ground up to be network transparent'.
I'm afraid that the limitations such as the above come from X's origins as a black and white, pixel based protocol for allocating rectangles on a screen -- all else is (and appears to be) an afterthought.
John
I don't know about KDE 2, but to make the point clear, Drag and Drop should be TRIVIAL to add to a program (you should just 'declare the GUI object as draggable' and the UI logic should do the rest)
John
A JAVA GUI system with the baggage of X and CDE removed would probably be faster and less of a memory hog than CDE.
John
Standards conformance.
John
You could just say 'prouced'. The basic point is the same -- RAD. Application developers shouldn't have to do intricate component development (i.e. going through code with a fine toothcomb, removing wasted instructions etc.). When was the last time you heard someone complain that 'mending a car' wasn't really mending since 'you don't have to do all the complicated bits').
John
John
The player will be integrated with Windows. (It's all paid for by the M$ tax)
John
Think 'little theorem'.
For example, when proving a major theorem in some research paper, you'll write some smaller things building up to your main result(s) in 'lemmas'.
What the previous poster is referring to is sets of 'when this holds, so does this' type implications (e.g. if a is invariant bc and ca, we know that ba and don't need to work this out explicity)
John
It's a Terminator reference -- SkyNet is the 'evil AI system'
John
True, but languages that punish bad code, rather than just accept it will have better (and usually less -- another improvement) code written for them.
Consider what would happen if you recieved a 40V electric shock every time you wrote bad code, or were in careless in some way -- there'd be less coders writing code, but the end result would be better (provided that the electric shocks were dealt out fairly -- and this is the problem of standardising...)
John
The point is being able to write 10x quicker, and have everything run within x% of the original.
This is an important point in practice -- do you want to spend ten times more in order to get something 5% faster? The idea of microkernels, abstraction layers, etc. is to make other peoples lives easier, whilst still being fast enough.
John
The major difference in the compile/run cycles will be that there is no (this is source, this is intermediate, this is compiled) dividing lines -- anything goes :-)
John
Dont be so sure. Compilers typically generate static (i.e. unchanging) code. At best this can be statically optimal for a given task.
However it has been demonstrated (I think that some people at MIT have done this, among others), that statically optimal code is not necessarily the fasted, and dynamic optimisation can increase speed further. (The compiler DOESN'T know what the JIT can find out during runtime, and no amount of minutes spent sitting and thinking can change that)
John
The why are the fastest numerical libraries the hand-coded ones? answer: The people doing the coding know things that the computer couldn't possibly. Current languages don's have the structure/semantics/etc. required to convey various mathematical know-how required to clever optimisations (how many compilers will recognise an operation similar to a discrete Fourier Transform and put an FFT in place -- you should note that large number multiplication usually uses such tricks)
John
Nope -- the JIT compiler compiles each .class file into native machine code each time the .class is loaded afresh. Further, it may (at its option) recompile the methods of the .class using different parameters (found by profiling).
John
How do I put the menu for the current application at the top of the screen? How do I add some global options to the menus? Also known as 'Pie menus' think of a circle appearing at where the mouse was clicked, subdivided like a pie chart, such that you, say, go left for formatting details, right for copy. Thats eye-candy, nothing more. You can't change the feel or logical arrangement of a GNOME or KDE application with the theme alone. Pardon?? (All I've ended up using is Sawmill, wterm and Xemacs.) There is NO global scriptability for GNOME applications, and similarly for KDE in 1.x. KDE 2.x may be different, I hope so.
There is little flexibility at the application level (like you get with various Windows applications -- GNOME and KDE applications aren't mature/bloated enough for that, and wouldn't get sufficient development anyhow) If your preferences or prejudices relate to simplicity of design, overall thought of design, plans for future, etc. then I'm afraid that that just isn't the case. what needs to be stressed, and isn't is Flexibility, Reuseability, possiblities for Customisation/Integration at the component level -- currently KDE 1.x and GNOME 1.x have no real concept of a component level. True, but it is all too often that the people in charge see the cosmetic factors in their competition, and go all out to emulate those and only those without the thought that has gone in to the rest of the design of what they aspire to copy. The moral of this story is: Think, Think and Think again before you code something that you want to put out (TAI -- Linus didn't think about global users when starting Linux, and didn't distribute it until it was going somewhere, and he's stuck to his aims ever since.)
John
So much can be attributed to X There are so many interesting, intuitive ideas as to UI design that can be easily stated, but no-one has a clue how to actually implement in X (let alone simply, efficiently,properly,etc.)
Given that X allows for rectangles to be allocated and a little rudimentry communication between them, it is suprising that people have got so far as they have. Then there are the 'but X is a standard' people that insist that X should be that center of the UI. They can, in a number of cases, appear to back this up by showing that a given feature can be done with X. But what is basically impossible (see what KDE/GNOME are doing to try and manage this) is integration -- when the centre of the UI management has no concept of applications, documents, menus and cannot be told about them. Too true. What is lacking is documentation of decisions relating to the design, justification of those decisions, and discussions of alternatives, and why not them. The discipline alone in doing this would go a long way to improving design (and would probably resunt in X being dropped a whole lot quicker) What is needed is for it to be easier by a long way to make simple changes that are extended over the UI, or ove the system (given the relevant permissions) such that differences can be experimented with easily.John