Nope, that doesn't get the idea across. Berlin attempts to replace the GUI libraries like QT, Xt, GTK,...
Berlin depends on there being some lower-level display substrate like GGI.
It would make sense to implement Berlin atop X; implementing it atop QT, of whatever form, would not make sense.
What could make sense would be to implement Berlin (or, by the same token, X or Display Postscript) atop whatever low level framebuffer scheme lies underneath Embedded QT. But I suspect that this layer will more closely resemble GGI than anything else...
There would be similarity to Berlin, but not to GGI.
"Embedded QT" represents an abstract API for constructing GUI apps. That does parallel Berlin.
GGI represents a physical API that abstracts away only the lowest level of "talking to hardware."
The net result is that you might want to run "Embedded QT" on top of GGI, much as you have to run Berlin on top of GGI.
In the process, it's pretty evident that you'll lose the ability to have remotable network applications with "Embedded QT." (Berlin has no such loss, as it runs atop CORBA...)
The thing that I don't see any information on is what they're doing about font rendering. That's one of the major things that X does which a framebuffer doesn't do...
Note that St. Petersburg State University has a similar organization of having a Mathematics and Mechanics Faculty. It probably used to be called Leningrad State University back before "glasnost."
I could go with either MSU or St. Petersburg as being "the ones." St. Petersburg has been doing very well in the ACM contests, which suggests that they are likely rather good.
Whether that's from student selection ("nature") or quality of teaching ("nurture"), or some combination of both, is another question...
Waterloo has been placing in the top six quite regularly, of late.
No US institutions have been placing in the top 4, or, this year, in the top ten.
Not MIT. Not CMU. None of the UC schools. Not Stanford.
The one non-apathetic thing I did in my time at UW was to help get teams heading back to the ACM Scholastic Programming Contest. That was quite a lot of work, and not terribly worthwhile at the time. It sure feels worthwhile now...
They validly comment that cats are not particularly "uniform."
Much like the mythical "geek" group, as well as, as you observe, "Christians."
The big problem (as opposed to other, "small" problems), is that cats aren't herding creatures. And while I may not be "cat people," it's fair to say that "geek people" are similarly resistant to "herding."
The EDS commercial makes the mistake of suggesting that it is vaguely sensible to try to herd cats. The problem is that it's not even faintly sensible. Neither cats nor geeks "herd" well. Trying to do so is going to lead to managerial disaster.
And fielding a "geek candidate" is not going to be good for other than the small subset of "geeks" that go along with the particular geek's position.
And some ( David McCusker, of OpenDoc/Bento/IronDoc "fame" comes particularly to mind...) seem so independently-minded that the "lobbies" are not likely to represent them at all.
And actually, the commonly-recognized minorities of women and whatever is the politically-correct way today of referencing people that are definitely not melatonin-deficient that likely have roots in Africa, but which may not have any connection to America are not perfectly uniform in their needs and attitudes either...
The tendancy to being "personally peculiar," as well as being so strongly opinionated that some people ignore him as "too different" are parallels between Michael Hart and Richard Stallman.
Add to this that both hold extremely "populist" political positions that contrast sharply both with capitalists and "big government" socialists...
Despite some big storms of controversy, RMS has been somewhat more successful at attracting money to his efforts, mind you...
My suspicion is that both have, too often, backed themselves into extreme corners that have forced them apart from the "mainstream" in a manner that has been hurtful to their purposes. They probably don't need to disagree as much as they do...
It would certainly be nicer to get higher success rates, but if the venture provides launch prices that are a couple hundred million dollars cheaper than the alternatives, it can be worth losing a $100M satellite more often than merely "once in a while."
And they'll doubtless be looking to learn some things from the failure too, which may improve future chances of success...
Re:Arranging Things Not Necessarily Impersonal
on
Date Pagers
·
· Score: 2
I am a "white guy," and the coworker that "got it" was pretty much in the "white bread" category.
The important mistaken impressions people tend to have are the stereotypes of child brides and trading cows for people, and wives thrown onto the funeral pyre.
Some of which probably still occurs appallingly often...
Arranging Things Not Necessarily Impersonal
on
Date Pagers
·
· Score: 4
A good friend is on his way over to India to, very probably, get engaged.
The process, at least in this case, appears rather less bizarre than everyone seems to assume is the case for "arranged" marriages.
To the point, a year ago, there was an exchange of "resumes" that bore a striking resemblance to that which you might use to find an employer. (There's also a story about a "brother's boss's niece, but that's another story...)
In thinking about it, this really isn't particularly bizarre at all.
If all you're after is a sex partner for the evening, then probably an exchange of "medical resumes" would be in order, verifying that nobody's going to get an extra STD.
On the other hand, if a more "permanent" relationship is intended, an exchange of "personal resumes" and references can cut through a lot of the posturing and other dishonesty that happens as we pretend to be more attractive than we really are.
I mentioned the process to one of my married coworkers, and he at first thought arranged marriage to be a very peculiar thing, but then thought it might have been useful to have "character references."
Long and short is that these "tools" aren't necessarily any worse predictors of success than the "dating scene" that, with the divorce rates these days, are obviously not terribly good predictors of "relational success."
The point that the article (with great validity) makes is that the Internet doesn't introduce a whole lot of new taxable transactions.
If you buy that PC from a vendor that has an "operating presence" in your state, then you'll get taxed by virtue of the existing tax law.
If you buy the PC from a vendor where you don't get taxed, then this is a situation where mail-order transactions are not being taxed.
Note that the two situations described above have nothing to do with the Internet.
What, precisely, do you think you intend to have taxes applied to?
Be PRECISE. Tax law requires great precision. The practice of tax law involves examining transactions and determining how to determine how those transactions are to be taxed. "Sharp" tax practice involves presenting transactions in such a way that they are taxed less than they otherwise might be.
If you're proposing that there be some sort of "Internet Sales Tax," applied on top of other taxes, then you'll see a vast exodus of sales activity, as people will decide that if it will cost an extra $50 to put the request in via the Internet, then they'll just submit specs for the PC via the web site, and then phone in the purchase request, which will result in the transaction not being taxable.
One of the major merits of the "more heavily package managed" systems is that of being able to avoid many of the little, niggling details when they don't much matter, as well as being able to let the system manage version numbers for you.
The Ports use of what amount to "just plain makefiles" gives it the merit of being the most "traditionally-UNIX-like" packaging scheme.
Is there likely to be any "convergence" of the sort where libraries are added/modified so as to maximize the ability to use something like Ports?
I left Slackware in about '95 in favor of what I saw then as improved manageability of Red Hat's RPMs. I have since migrated to Debian, which provides better answers than RPM. It would be interesting to see the tide turn back due to Ports providing more deeply improved system manageability...
Did you have any expectation that they'd set up legislation that would mandate that if your PC gets hacked,
Janet Reno and her crack team of commando lawyers spring into action?
I don't even consider their rejection of creating new legislation to be "putting their heads in the sand." It is not an unreasonable idea to try to apply the existing laws.
It's fairly silly when legislators make up new legislation (that will never be enforced) in order to make it look like they're doing something about a problem to which existing laws ( that are also not being enforced) already apply.
Add in appropriate levels of cynicism as needed...
Yes, it's a bit vague. It's probably not enforceable from the perspective of a court of law.
The other problem is that there are all sorts of possible pathological cases.
For instance, Postscript is described as an "Opaque" format, but supposing someone follows the dictums of TINYDICT, and writes their documents in raw Postscript, then despite the fact that Postscript is usually considered "Opaque," it is, in fact, the "Transparent" form.
That's probably the most pathological (and perverse-sounding) case, and is one that I brought up in some discussions on the license last year.
HTML is a necessarily ambiguous form.
Many people do write documentation directly in HTML.
In such a case, HTML is the "most transparent form available."
On the other hand, if I write documentation using DocBook/SGML, and generate HTML from that, the "transparent" form is quite clearly DocBook.
In practice, I don't think this will be a big problem. After all, am I likely to sue someone for releasing "freely," under the "GDL," some documentation in a form that I don't much like? I think not...
The very cool thing (at least from my perspective!) is that some of the phrasing in there is mine. Originally, RMS had it worded as "SGML or XML," but that leaves things open to abuse if the DTD isn't disclosed. (Think "Word 2000, XML Version.")
At any rate, the point to "compilation copyright" and the "title page" stuff is that the goal is to provide a way of combining several requirements, including:
Providing authors with some right to acknowledgement of their authorship
Providing an ability to modify documents, but requiring some attribution of changes
Some reasonable ways to include "GDLed" documents with non-GDLed documents to create a collection
The net result can't be completely "clean."
As for "compilation copyright," the point of that is that a collection of documents can be copyrighted even if the components aren't. For instance, a phone book consists largely of a list of names of people and their phone numbers. The individual components aren't copyrighted, but the collection or "compilation" of them is.
In the same way, William Shakespeare's works are long out of copyright, but if I make a book that includes the plays along with some of my own commentary, the collection may become copyrighted, and you can only make copies at my sufferance.
The relevance is that there are vendors that put together collections of things like HOWTOs, and the GDL needs to have some rules to indicate how it interacts with the needs of such "collections.."
The "hot swap everything" feature is vastly more related to the hardware design than to the OS design.
If you pull the CPU out of your PCI bus system while it's running, it is Rather Likely that you'll do severe damage to the hardware.
The more we see things like USB, I2O, and serial IDE, where there are I/O controllers independent of the CPU, the more there will be an ability to attach/detach peripherals while the system is running. And if there was a motherboard that provided a "protocol" to allow connecting/disconnecting CPUs and memory online, that would be a further extension of this.
Mind you, the cost of allowing such a "protocol" would likely substantially increase the cost of the motherboard, and people are generally price sensitive particularly to things that they rarely fiddle with, which discourages adding this feature to any computer systems that any of us can afford to buy...
It's not sensible to consider that it has become intuitive.
What has happened is that Windows has become part of peoples' learned expectations.
Much as with English, people have learned about its warts and aspects of non-intuitiveness, and have figured out how to work around them.
If something is truly intuitive, this means that there is no learning process required. The thing in question simply works the way people expect.
UNIX has the merit that it is a simple enough computer system that some people can get a sufficiently accurate model of its operation so that it becomes possible to predict what it will do.
In contrast, as soon as you strip the veneer of "learned things about its behaviour" off of Windows, it's a richly complex system whose behaviour is much more difficult to predict. (The lack of source code or other disclosures don't help either...)
The above approach to "intuiting" about Windows and UNIX take a rather different tack than the usual, assuming that the individual will actually try to deeply understand the system. It replaces the "black box" with one that is expected to be understood.
Rather unlike the usual model of trying to know nothing about what is going on behind the curtain...
The "create a free Multics clone" idea comes up periodically on the Usenet newsgroup alt.os.multics.
It runs up against several problems:
According to Multicians, an important aspect to Multics was the use of PL/I as the programming language.
There's not a "free" PL/I compiler.
Probably the nearest alternative would be to implement using the nearest thing to MacLisp, namely Common Lisp. But down that road lies the rather different path of creating a Lisp OS.
Another crucial aspect was the hardware support for memory management and rings.
Apparently Intel designed some Multics-like capabilities into some (not all!) members of the IA-32 series.
One alternative is to create a hardware emulator that emulates the Honeywell hardware. That would allow using existing Multics software, rather than merely involving creating analagous software.
Unfortunately, that means having to get access to the Multics software base, which is not likely terribly available these days.
The only system known to still be in production use is at DND: Maritime Command in Halifax, Nova Scotia, and its decommissioning is planned this year. Remember, military system. They're not likely to be willing to give out copies, independent of any rights Honeywell, Bull, and others may have...
Another option would be to create a "Multics shell" to parallel Ksh, Zsh,... and create a vaguely Multics-like environment atop Linux.
Of course, that doesn't get you segment/ring control, which hurts the emulation.
I've had Organick's book on Multics on order from Spamazon for a couple years, and have heard nothing. Some documentation may be hard to come by.
In effect, the problem with creating a Multics clone is twofold:
Determining a criterion for "Multicsness."
Does it have to run the same software? Does it have to use PL/I? Can it be upgraded with other modern notions?
Are you merely a racist bigot so inbred that you can't spell?
Or have you any useful comment as to why you would prefer one of GNOME/KDE?
Maddog observes that Linux is the only operating system that has ever had world-wide success that was not created in the United States. I'll take what he says a whopping lot over what some Anonymous Coward too cowardly to put name to his words.
Did I forget to mention that you can't spell? No? Oh, well, it probably ought to be underlined...
The "desktop conflict" largely represents one between people not capable of doing development work for either system.
The fact that KDE tends to be popular near Germany, and GNOME tends to be popular around North America, provides for all sorts of entertaining "Godwin's Law"-related possibilities. But is largely irrelevant to the people that are actually working on making these into useful systems.
My personal reaction is to sit with the French in the "danger zone," and say Vive la difference!
BOTH desktops can coexist, (particularly in these modern days of 36GB hard drives), and both have valid things to offer.
The problem is that XML merely provides a data format. It does not inherently provide a robust way of rewriting files, which is what is truly important for a configuration system.
I'd think it more valuable to, on a case-by-case basis, adopt libPropList. That provides the benefit of a relatively generic format, but, more importantly, with the merit that it comes with library calls to modify data, and to do so in a safe way.
Slashdot Mirror
Berlin depends on there being some lower-level display substrate like GGI.
It would make sense to implement Berlin atop X; implementing it atop QT, of whatever form, would not make sense.
What could make sense would be to implement Berlin (or, by the same token, X or Display Postscript) atop whatever low level framebuffer scheme lies underneath Embedded QT. But I suspect that this layer will more closely resemble GGI than anything else...
"Embedded QT" represents an abstract API for constructing GUI apps. That does parallel Berlin.
GGI represents a physical API that abstracts away only the lowest level of "talking to hardware."
The net result is that you might want to run "Embedded QT" on top of GGI, much as you have to run Berlin on top of GGI.
In the process, it's pretty evident that you'll lose the ability to have remotable network applications with "Embedded QT." (Berlin has no such loss, as it runs atop CORBA...)
The thing that I don't see any information on is what they're doing about font rendering. That's one of the major things that X does which a framebuffer doesn't do...
The Faculty of Mathematics and Natural Sciences at Universiteit Leiden has a somewhat similar organization, but I'd consider MSU a much better candidate.
Note that St. Petersburg State University has a similar organization of having a Mathematics and Mechanics Faculty. It probably used to be called Leningrad State University back before "glasnost."
I could go with either MSU or St. Petersburg as being "the ones." St. Petersburg has been doing very well in the ACM contests, which suggests that they are likely rather good.
Whether that's from student selection ("nature") or quality of teaching ("nurture"), or some combination of both, is another question...
- Waterloo has been placing in the top six quite regularly, of late.
- No US institutions have been placing in the top 4, or, this year, in the top ten.
The one non-apathetic thing I did in my time at UW was to help get teams heading back to the ACM Scholastic Programming Contest. That was quite a lot of work, and not terribly worthwhile at the time. It sure feels worthwhile now...Not MIT. Not CMU. None of the UC schools. Not Stanford.
Much like the mythical "geek" group, as well as, as you observe, "Christians."
The big problem (as opposed to other, "small" problems), is that cats aren't herding creatures. And while I may not be "cat people," it's fair to say that "geek people" are similarly resistant to "herding."
The EDS commercial makes the mistake of suggesting that it is vaguely sensible to try to herd cats. The problem is that it's not even faintly sensible. Neither cats nor geeks "herd" well. Trying to do so is going to lead to managerial disaster.
And fielding a "geek candidate" is not going to be good for other than the small subset of "geeks" that go along with the particular geek's position.
And some ( David McCusker, of OpenDoc/Bento/IronDoc "fame" comes particularly to mind...) seem so independently-minded that the "lobbies" are not likely to represent them at all.
And actually, the commonly-recognized minorities of women and whatever is the politically-correct way today of referencing people that are definitely not melatonin-deficient that likely have roots in Africa, but which may not have any connection to America are not perfectly uniform in their needs and attitudes either...
I'm not so concerned about Elbrusian technology as I am about Elbonian technology.
Add to this that both hold extremely "populist" political positions that contrast sharply both with capitalists and "big government" socialists...
Despite some big storms of controversy, RMS has been somewhat more successful at attracting money to his efforts, mind you...
My suspicion is that both have, too often, backed themselves into extreme corners that have forced them apart from the "mainstream" in a manner that has been hurtful to their purposes. They probably don't need to disagree as much as they do...
The evaluation has nothing to do with any technical meaning of "best," but merely the notion of "most sold by retailers."
In which situation Debian obviously disappears, regardless of whether it has any valuable qualities or not.
And they'll doubtless be looking to learn some things from the failure too, which may improve future chances of success...
The important mistaken impressions people tend to have are the stereotypes of child brides and trading cows for people, and wives thrown onto the funeral pyre.
Some of which probably still occurs appallingly often...
The process, at least in this case, appears rather less bizarre than everyone seems to assume is the case for "arranged" marriages.
To the point, a year ago, there was an exchange of "resumes" that bore a striking resemblance to that which you might use to find an employer. (There's also a story about a "brother's boss's niece, but that's another story...)
In thinking about it, this really isn't particularly bizarre at all.
If all you're after is a sex partner for the evening, then probably an exchange of "medical resumes" would be in order, verifying that nobody's going to get an extra STD.
On the other hand, if a more "permanent" relationship is intended, an exchange of "personal resumes" and references can cut through a lot of the posturing and other dishonesty that happens as we pretend to be more attractive than we really are.
I mentioned the process to one of my married coworkers, and he at first thought arranged marriage to be a very peculiar thing, but then thought it might have been useful to have "character references."
Long and short is that these "tools" aren't necessarily any worse predictors of success than the "dating scene" that, with the divorce rates these days, are obviously not terribly good predictors of "relational success."
- If you buy that PC from a vendor that has an "operating presence" in your state, then you'll get taxed by virtue of the existing tax law.
- If you buy the PC from a vendor where you don't get taxed, then this is a situation where mail-order transactions are not being taxed.
Note that the two situations described above have nothing to do with the Internet.What, precisely, do you think you intend to have taxes applied to?
Be PRECISE. Tax law requires great precision. The practice of tax law involves examining transactions and determining how to determine how those transactions are to be taxed. "Sharp" tax practice involves presenting transactions in such a way that they are taxed less than they otherwise might be.
If you're proposing that there be some sort of "Internet Sales Tax," applied on top of other taxes, then you'll see a vast exodus of sales activity, as people will decide that if it will cost an extra $50 to put the request in via the Internet, then they'll just submit specs for the PC via the web site, and then phone in the purchase request, which will result in the transaction not being taxable.
RPM is the most-used, and often, most-hated of the options, with Debian's dpkg/dselect and BSD Ports vying for the "most-loved" status.
The Ports use of what amount to "just plain makefiles" gives it the merit of being the most "traditionally-UNIX-like" packaging scheme.
Is there likely to be any "convergence" of the sort where libraries are added/modified so as to maximize the ability to use something like Ports?
I left Slackware in about '95 in favor of what I saw then as improved manageability of Red Hat's RPMs. I have since migrated to Debian, which provides better answers than RPM. It would be interesting to see the tide turn back due to Ports providing more deeply improved system manageability...
I don't even consider their rejection of creating new legislation to be "putting their heads in the sand." It is not an unreasonable idea to try to apply the existing laws.
It's fairly silly when legislators make up new legislation (that will never be enforced) in order to make it look like they're doing something about a problem to which existing laws ( that are also not being enforced) already apply.
Add in appropriate levels of cynicism as needed...
The other problem is that there are all sorts of possible pathological cases.
For instance, Postscript is described as an "Opaque" format, but supposing someone follows the dictums of TINYDICT, and writes their documents in raw Postscript, then despite the fact that Postscript is usually considered "Opaque," it is, in fact, the "Transparent" form.
That's probably the most pathological (and perverse-sounding) case, and is one that I brought up in some discussions on the license last year.
HTML is a necessarily ambiguous form.
In such a case, HTML is the "most transparent form available."
In practice, I don't think this will be a big problem. After all, am I likely to sue someone for releasing "freely," under the "GDL," some documentation in a form that I don't much like? I think not...
At any rate, the point to "compilation copyright" and the "title page" stuff is that the goal is to provide a way of combining several requirements, including:
The net result can't be completely "clean."
As for "compilation copyright," the point of that is that a collection of documents can be copyrighted even if the components aren't. For instance, a phone book consists largely of a list of names of people and their phone numbers. The individual components aren't copyrighted, but the collection or "compilation" of them is.
In the same way, William Shakespeare's works are long out of copyright, but if I make a book that includes the plays along with some of my own commentary, the collection may become copyrighted, and you can only make copies at my sufferance.
The relevance is that there are vendors that put together collections of things like HOWTOs, and the GDL needs to have some rules to indicate how it interacts with the needs of such "collections.."
If you pull the CPU out of your PCI bus system while it's running, it is Rather Likely that you'll do severe damage to the hardware.
The more we see things like USB, I2O, and serial IDE, where there are I/O controllers independent of the CPU, the more there will be an ability to attach/detach peripherals while the system is running. And if there was a motherboard that provided a "protocol" to allow connecting/disconnecting CPUs and memory online, that would be a further extension of this.
Mind you, the cost of allowing such a "protocol" would likely substantially increase the cost of the motherboard, and people are generally price sensitive particularly to things that they rarely fiddle with, which discourages adding this feature to any computer systems that any of us can afford to buy...
Mark Miller (who has a really cool web page on advanced OS stuff) used to have a page on Hydra; seems to be gone now, unfortunately.
Hydra was a capability-based system, and is likely moreso a parent of EROS than it is a child of Multics...
What has happened is that Windows has become part of peoples' learned expectations.
Much as with English, people have learned about its warts and aspects of non-intuitiveness, and have figured out how to work around them.
If something is truly intuitive, this means that there is no learning process required. The thing in question simply works the way people expect.
UNIX has the merit that it is a simple enough computer system that some people can get a sufficiently accurate model of its operation so that it becomes possible to predict what it will do.
In contrast, as soon as you strip the veneer of "learned things about its behaviour" off of Windows, it's a richly complex system whose behaviour is much more difficult to predict. (The lack of source code or other disclosures don't help either...)
The above approach to "intuiting" about Windows and UNIX take a rather different tack than the usual, assuming that the individual will actually try to deeply understand the system. It replaces the "black box" with one that is expected to be understood.
Rather unlike the usual model of trying to know nothing about what is going on behind the curtain...
But it sure looks like UNIX has its multiuserness at a reasonably deep level. Can you elaborate on the lack of UNIX multiuserness, perchance?
It runs up against several problems:
- According to Multicians, an important aspect to Multics was the use of PL/I as the programming language.
- Another crucial aspect was the hardware support for memory management and rings.
- One alternative is to create a hardware emulator that emulates the Honeywell hardware. That would allow using existing Multics software, rather than merely involving creating analagous software.
- Another option would be to create a "Multics shell" to parallel Ksh, Zsh,
... and create a vaguely Multics-like environment atop Linux. - I've had Organick's book on Multics on order from Spamazon for a couple years, and have heard nothing. Some documentation may be hard to come by.
In effect, the problem with creating a Multics clone is twofold:There's not a "free" PL/I compiler.
Probably the nearest alternative would be to implement using the nearest thing to MacLisp, namely Common Lisp. But down that road lies the rather different path of creating a Lisp OS.
Apparently Intel designed some Multics-like capabilities into some (not all!) members of the IA-32 series.
Unfortunately, that means having to get access to the Multics software base, which is not likely terribly available these days.
The only system known to still be in production use is at DND: Maritime Command in Halifax, Nova Scotia, and its decommissioning is planned this year. Remember, military system. They're not likely to be willing to give out copies, independent of any rights Honeywell, Bull, and others may have...
Of course, that doesn't get you segment/ring control, which hurts the emulation.
Does it have to run the same software? Does it have to use PL/I? Can it be upgraded with other modern notions?
Are you merely a racist bigot so inbred that you can't spell?
Or have you any useful comment as to why you would prefer one of GNOME/KDE?
Maddog observes that Linux is the only operating system that has ever had world-wide success that was not created in the United States. I'll take what he says a whopping lot over what some Anonymous Coward too cowardly to put name to his words.
Did I forget to mention that you can't spell? No? Oh, well, it probably ought to be underlined...
The fact that KDE tends to be popular near Germany, and GNOME tends to be popular around North America, provides for all sorts of entertaining "Godwin's Law"-related possibilities. But is largely irrelevant to the people that are actually working on making these into useful systems.
My personal reaction is to sit with the French in the "danger zone," and say Vive la difference!
BOTH desktops can coexist, (particularly in these modern days of 36GB hard drives), and both have valid things to offer.
I'd think it more valuable to, on a case-by-case basis, adopt libPropList. That provides the benefit of a relatively generic format, but, more importantly, with the merit that it comes with library calls to modify data, and to do so in a safe way.