Well, because they tend to be simple, lightweight and robust, and also because of the difference in philosophy when you compare them to protocols originating in the telco world. Those former are designed in terms of black boxes and the exact way they perform their function first, [...]"
In the last sentence, stike 'former'. I'm referring to the telco protocols, not the internet ones.
Agreed that a runtime can be made platform-specific, but isn't this just another abstraction layer? What is the difference between the runtime and an abstraction layer for GUIs in C++, in terms of cross-platform GUIs?
Of course a runtime is just another abstraction layer. But the thing is that a runtime that provides a virtual platform, shields the program that runs on it from the real host platform. As such, the portability problem is solved separately from the main problem. Remember that I'm not arguing that cross-platform GUIs are impossible in C++, I just say that a language such as C or C++ that has the API of the host platform as its primary toolbox, encourages you to write single-platform applications, and makes it hard(er) to do cross-platform ones.
The strange part is that you've mentioned three of the most famous portable APIs (or, more accurately, API protocols) that are not tied to any language - as examples of why we need portable APIs that are not tied to any language.
That's not strange, that illustrating my point: apparently there is a need for such things. But I think they're following an approach that to me seems needlessly complicated.
And they are, as you said, 800lb gorillas.
That's my objection to them.
And can you elaborate on "put the interface at every conceivable place"?
That's the cause of it as I see it. These protocols allow you to define the interface between any two objects, i.e. they support each and every inter-object communications scheme you can think of supported by every conceivable language. You can export any native object, so to speak, and expose it to the outside world, without limits in functionality.
Can you elaborate on this idea? [data-centric APIs] I like it, but I'm not sure I'm completely following your "thin as possible" line of thinking (what does that mean?)
Well, defining an API in terms of pure data messages encourages you to place the interface between your components in such a way that you need the least amount of different message types, and the smallest number of (interrogation) transactions before doing the actual work.
An API defined in terms of function/method calls that look the same as local ones, doesn't make it seem like much of a problem to have lots and lots of calls from component A to B and from B to A, because it doesn't put the fact that each call must be put through that big remote object layer, firmly in your conscience while developing.
And why should it be like an internet protocol?
Well, because they tend to be simple, lightweight and robust, and also because of the difference in philosophy when you compare them to protocols originating in the telco world. Those former are designed in terms of black boxes and the exact way they perform their function first, and then you look at the information they need to pass between them for each to perform its particular function. Naturally, the resulting protocol will express a lot of how the design and implementation of those black boxes turned out.
But for most internet protocols the intelligence is put more in the data, and the messages themselves tend to get designed in detail before the endpoints are. You basically imagine what each side of the 'wire' theoretically needs to know of the other, and design a way as simple and generic as possible to transmit that information, and you design the black boxes at the endpoints as a next step. Of course this is overstating things a bit in practice, but you get the idea.
The difference is that you're not modeling the protocol to some specific, already designed, detailed endpoint implementation, but to a generic model you've got in your head. Such a protocol will in most cases allow alternative implementations to be done much more easily, and you can see from the number of different implementations for most internet protocols that this is true.
What am I getting at with this? Simply this. Messages (data) are *much* more portable than code libraries; you only need to sort out relatively easy endianness and word size issues, and you're done. So an API defined in those terms will always be much more portable than APIs defined in terms of *functions*, which will always be tied to a particular language, whether that's a native language such as C++, a language that runs on a virtual platform such as Java, or a complex abstract interface description language such as IDL.
If a protocol or API is so complex that the easiest way to port it to a new platform/language is to port a particular code library that implements it to a new platform/language, then it has failed as a protocol, IMHO.
> OTOH, I'd love to see you write a full-blown word processor or a 3D FPS game in HTML and JavaScript.
Exactly. That's why we need something that's much more lightweight, and that's why I said technologies such as XML-RPC are not going to solve the API-as-a-protocol problem.
Something that's a well-balanced rebirth of the X windows protocol, DPS or Apple's Display PDF and HTML + JavaScript combined, that is expressive enough to define much of a GUI in, and at the same time lightweight enough to allow things like games to work.
"Q: Standard C++ doesn't support modern programming concepts such as multithreading, distributed computing, components, and persistence. The result is a plethora of proprietary libraries and platform-dependent frameworks that make cross-platform development in C++ nearly impossible. Is Standard C++ still relevant? Which features would you like to see added to the language in the future?
A: Again, these questions arise from an overstated premise. Thousands of companies are routinely writing and shipping cross-platform software written in C++. Claiming that it's "nearly impossible" doesn't change the fact that we've been doing it for years. The one big area I can think of where portability is genuinely difficult is one the question didn't mention -- GUIs. GUI portability is a problem in all languages, unless you give up writing rich GUIs and write only simple and limited ones. Interestingly, despite some languages' attempts to "standardize" cross-platform GUI libraries, the best and most successful solution for cross-platform GUIs is not a code library at all, but HTML."
Well, that proves the point, doesn't it -- HTML + JavaScript is apparently a "language" that people find better suited to define standard, cross-platform GUIs in than C++!
The reason may very well be that C++ GUIs tend to they tie in to too many features of the underlying platform to be portable. If you/do/ want portabilty, you're on your own: you'll have to invent your own abstraction layer in order to achieve it. Obviously, some succeed better than others in that respect, and as he says, it doesn't keep people from trying.
It seems that any language that uses a runtime (for HTML+JavaScript, that's the browser; for Java, that's the JVM; for Scheme, that's Emacs:P), is much better for offering cross-platform services and libraries, simply because the burden does not lie upon each and every individual library developer anymore to create a platform abstraction layer. That only has to be done once, by the runtime.
Really, this is not exactly a mind-shattering concept (USCD-Pascal on p-Code anyone?)
Not that the current state of affairs with HTML+Javascript or Java gives much reason to feel content, but I *definitely* still see the point of having a runtime that offers a standard, special-purpose language to define GUIs.
However, I think the API for such a runtime should be viewed more as a data protocol than as a set of language-specific functions to call.
And *that* really applies to more than just GUIs: there really is a need for portable APIs that are not tied to any language these days, if you look at those complex, horrible 800lb monstrosities like Corba, COM or.NET. But I think the reason why these are so big and ugly is because they want to make it possible to put the interface at every conceivable place. Of course the interfaces will be complex if you do that.
Why not focus on *data-centric* APIs instead, that are intended to be put where the interface is as thin as possible, and build them as efficient and robust as an internet protocol should be?
If you're thinking of XML now, that may be close, but I really can't see how XML is the most efficient and easy-to-implement way of transmitting trees of attribute/value pairs. It's too difficult and slow to parse, to start using it as a transport for local subsystem calls as well, and contains too much redundancy, such as named close tags.
What the Internet and your local system needs is a good OSI layer 5. Is HTTP + XML really the best thing we can come up with?
A slogan might be handy for a billboard campaign as well.
The law's new name seems to offer a lot more possibilities for that than the old one. Things like "CBDTPA: Consume Broadband only like Digital Televison, or be Punished in America", or "Consumer Broadband Doubles Tariff Per Annum", or "CBDTPA Changes Binary Devices To Perverse Apparatus" spring to mind.
As others have said earlier, it's probably next to impossible to have 100% compatibility, unless you re-implement all of Word itself.
What is needed more, and what's probably much more practical to achieve, is the ability to *safely edit* Word files!
That means *no* lossy import to suite X, followed by a lossy export to Word again, resulting in a document that doesn't even resemble the original one.
An alternative office suite needs to preserve all the bits and pieces of the Word document it doesn't understand; never mind that they won't look correctly or can't be edited at all.
At least you can then choose for yourself whether you want to live with the limited compatibility. But people won't shout at you anymore for messing up their document when you've corrected some text or filled out a Word form.
I agree. Your last remark (the need for server-side toolkits) also hits home IMHO, and I'd suggest a few more things for them:
1. the elements in these toolkits must be able to be defined in terms of server primitives orother elements, using a platform independent special-purpose language. And not only their appearance but also where simple interactions are concerned, such as a 'down' button that moves a slide down and a scrollable view up;
2. the server must be able to receive these definitions from the client itself or to fetch it from an external source on behalf of the client (honor server security by making sure the definition language's scope is limited to the user interface only);
3. the server must be able to cache these elements using unique identifiers by which they can be referenced. These should have two parts: a functional part and an appearance part. Clients specify an element's functional part as a requirement, and its appearance part as a hint, in order for users to be able to provide alternatives (i.e. theme support);
4. a proper encryption and authentication model for the X channel.
This makes the server able to operate more independently, instead of requiring a round trip to the client for every simple operation, making operation over low-security, low-bandwith, high-latency networks such as the internet *much* more practical.
Potentially, this would provide a lot more elegant distributed computing model than the whole mess we have now for exporting user interfaces, with http, html, the DOM, jscript and all those gross hacks that seem impossible to get right if you look at today's browsers.
FWIW, I'd make that boundary equivalent to the boundary between address spaces.
That distiction is good, because programs that share address spaces can alter each others behaviour in arbitrary ways, because they have full access to each others internal variables, whereas otherwise, each program stays in control of its own behaviour and is free to choose how it reacts to input from the other program.
IOW, communicating with a program through its intended I/O channels, be it files, Unix- or TCP sockets or otherwise, never makes a derivative work, because each program is still free to perform its intended function, which may not be the case for linked objects.
Well, what you can do in the mean time is to wait for processes that can still run to exit gracefully on their own, possibly handling the condition of a malloc() returning NULL.
Of course, because processes tend to wait on each other sometimes, this can still cause nasty deadlocks.
But combined with a number of physical pages that you reserve until you reach OOM condition (cannot free up memory regardless of how hard we try), which even then become available only for processes having uid 0, so that a human root can always get a shell and run kill -9 to break those deadlocks, this could still be an alternative.
I don't care in the least that it's Microsoft and not Apple or Real who succeeded in getting their proprietary format accepted by the electronics manufacturers; the real problem is properietary media formats, period.
The bigger problem is that none of the people in charge (the media industry) has any interest in formats with open specifications, because that would defeat the scheme to move everything to pay-per-view that is taking place:
* closed media formats + anti-reverse engineering laws give control over which players you can use, and
* closed players + anti-circumvention laws give control over how many times you can enjoy the content before having to pay again.
Question number one: does the Australian government really want to put the restriction on media that all of its content must be suitable for minors?
If they recognise published media as one of the ways humans share their culture, do they really intend to lower the intensity of all cultural expression to a level that can be safely handled by children?
I think that many of the most interesting works of art have a serious unsettling effect, even on adults. Perhaps that's what makes them interesting, and what can make peoples life richer after experiencing them.
Of course people should be cautious about the human expressions and experiences a child is ready for. For example, one of the things that I would consider way too intense for children is the amount of manipulative advertising targetted at them. I can hardly imagine a lower and more harmful form of human culture.
I also keep being surprised about how much governments talk about censoring cultural expression from individuals, and so little about limiting targetted expression from companies, who only have responsibilities to their shareholders - but I digress.
Question number two: suppose that the Australian government succeeds in enforcing their restictions on content that is published in Australia, how will they deal with the fact that this will have hardly any effect the content that is/available/ in Australia?
Will they then attempt to make viewing certain content illegal, if they find out they cannot control what people publish in less restrictive countries, and that they cannot control what makes it into Australia, because the objects transported across their borders are pure bitstreams, which are not recognisable as human expressions of any type during their transport?
Only if the internet would indeed work by a form of manual mirroring, with little dwarfs feverishly reading all internet content from abroad and re-publishing it on domestic servers, then national censorship would work.
It's just a pity that a lot of politicians' imagination does not seem to be capable to extend much beyond this idea. Who knows, it may just be the lack of exposure to human culture that has limited the development of their imagination...
Sounds nice in theory, but I think that the biggest stumbling block for such interoperability is that the file format and the semantics of the data stored in it, are tied incredibly tight to the model used in Word to represent documents, and probably just as much to Word's particular implementation of it.
Think problems like 'the third octet of the.doc file contains the value of the variable FooBar' where FooBar is something entirely implementation-specific.
The people who developed Word had no incentive at all to make things more abstract, because Word's whole business model is mostly based on the idea that Word documents can only be used reliably with Word.
What we need instead is a better document editing paradigm and a portable format that goes with it. We can only be worse than Word itself as long as we try to imitate it. And there can be no conversion filter that's actually usable without imitating Word's document models.
Gecko's home page doesn't render on NS4!
on
Galeon 1.0 Released
·
· Score: 4, Interesting
It seems these people are trying to make damn sure you'll become painfully aware of the need for a browser that does all those playful CSS/DHMTL things.
Using NS4, their pages come out *completely* garbled.
But I won't switch anywhere soon. Why not? Because I don't *want* an application that's supposed to be simply a client for *simple, transaction based UIs*, that is bigger than my unix kernel and X together.
I think this situation is a damn shame, and proves to me the failure of the whole HTML concept. "Logical/structural document layout" instead of physical layout may be nice in theory, but a. what's the use if it can't even auto-generate tables of contents or anything that'd make structural markup actually *useful*, and b. the idea that every type of UI can follow a document model, and that every document can follow some hierarchical content model was an rare case of hybris, if you ask me.
It's probably OK for scientific papers, which all have *very* similar structure. But you need a *ridiculous* amount of complexity to try and squeeze every application UI in the same model. And it shows.
I think we should do something else; create a UI description language that's NOT a document markup (HTML), not a pre-downloaded 'interactive' animation script (Flash), not a general-purpose programming language (Java), and not a rigid, low-level protocol like X; rather a network-transported language in which you can describe widgets and simple interactions between them in terms of lower-level widgets and UI elements. Think 'interactive' postscript (but with infix notation). Or *something*.
Then we can finally push the UI, *only* the UI, but as much of it as possible to the client, and have clients keep an open (tcp) connection to the application that can be as stateful as it likes. Whatever.
But it should be possible to finally find a good middle ground between X and HTTP+HTML. There's *got* to be a way.
Any thoughts? Does anybody know of such a project?
From the looks of it, this seems more than a bit serious. Would perhaps being dependent to a large extent on 'downstream' maintainers (who take care of the packaging) be part of the problem?
Perhaps people should encourage 'upstream' developers more to accept debian package building specs as part of their base tree.
As a developer, you still need to know a bit of how the packaging system works, but it would probably make you feel more responsible if it's included in your own releases.
Perhaps I'm way off and this all has nothing to do with it though...
Depends on your interfaces, of course. If you want to bind the modules together by having them freely call each others functions, this can and probably will become a debugging nightmare.
However, for those cases where you'd already go for a multiprocess design, using a clean protocol that's spoken between the modules, it can be quite a good idea to exploit the simple fact that some languages are better at some things than others.
Eg. my current project, OpenRADIUS has a C core that does low level packet handling, job scheduling, etc., and a module that happens to be written in Perl to easily deal with simple and more complex formatted ASCII tables.
If I would have had to write that module in C as well, it would *definitely* have taken me a lot more time.
I don't understand why you think precedence is something that's a "confusing" concept in general. I was taught that multiplication comes before addition in primary school...!
Also, because these rules don't tend to change in a language, I fail to see how relying on precedence makes code hard to maintain or easy to break ("brittle"). It won't break spontaneously, if that's what you mean. Somebody who does not know the language's rules has to come along and edit your code first.
If you're using a language for expressions, you've got to know the rules. When using any language with infix expressions, the precedence rules just belong to the rules that you're required to know, just as some other essential grammar rules for that language.
The only situation where you run into trouble is if you either believe that knowning grammar at all is optional, or that precedence rules don't belong to an infix expression language's grammar, and I don't think you can make a good case for either.
Hm. I'd say that there should be a very explicit question answered by the luser before a "document" can even make a "Click here" button (with a nasty action resulting from it) appear at all.
It should only be possible to cross the border between 'data' and 'program' after the user is presented with a very clear message about what he/she is about to do: allowing a new *program*, that's embedded in a *document*, to really do anything it wants with his/her computer.
Any attempt at stopping these worms without enforcing that border is futile, IMHO.
Well, ifdefs may not always be the right solution, but why not have a fork just at the platform level, instead of the whole tree? e.g. We'd have arch/alpha, arch/hugealpha, arch/x86, arch/bigx86, arch/embedx86...
If Linux didn't need a fork even when adding the 64-bit architectures, surely it should be possible to keep things like differently optimized memory managers in the same tree?
*Grin* Perhaps Jobs' thoughts wandered off during the meeting and remembered a GUI design discussion with Steve W. about whether to use single- or double clicks for certain actions... So at one point he suddenly shouted aloud: 'I want _one_ click!'
The rest is history.
I must admit, the guy is consistent in what he wishes...
What if the code morphing software authors (Hi Linus!) decided to 'extend' the X86 base instruction set just a bit, like 3DNow, MMX and so forth, only not to provide graphics acceleration, but to provide 'hints' to the code morphing software? In my imagination, there need be just a few of those extra instructions, and a clever compiler can stick them in to provide the code morpher with some difficult-to-find but static dependancy/ordering information. (I.e. potentially anything not needing run-time statistic gathering). If these hints are absent, the morpher just does its regular job. Now, good idea or not?
What kind of thing do you have in mind when you refer to 'native Wintel networking'...? Arpa's TCP/IP??? IBM's LanManager (you know, the thing with the shares that MS calls 'the core of microsoft networking')? Both things were created before windows even existed (but of course you already know that). So what exactly _do_ you mean?
Re:The 'four-processor' testbed
on
NOS Crossroads
·
· Score: 3
Erm... may I point out that Apache is, although not multithreaded in the sense of multiple threads in one process space, a multiprocess webserver? That means any SMP is taken full advantage of! I often find those buzzword-deep remarks about multithreading rather annoying, as the only reason IMHO it's hyped so much these days is because NT is so bad at IPC and creating processes. Also, what buggers me is the silly idea in the article that Apache would need to fork() for each request. This is nonsense, as you can configure as much pre-spawned servers as you want! So the reason why they suppose why apache whould perform worse than a multithreaded server escapes me. As to CGI, forget it, that _does_ need a fork(),execve() for each request. Rather, go fastcgi...! This way, application services can be prespawned too and reused between requests. Just my Hfl. 0.05...
Unless those robots have the three (four) laws that Asimov envisions (I wonder from who else you got that 'positron' idea;-), which are: 1. Do not harm any human, either by direct action or by neglegence; 2. Obey any human, except if the resulting action would violate law 1; 3. Protect yourself, except if the resulting actions would violate either law 1 or 2.
Asimov really goes to great depths exploring possible future societies that have this kind of robots; from their inception, people struggling to accept them, their odd behaviour, etc. But to stay on topic, he also wrote a book (it's called Children of the Sun, or something) about a society in which these robots are ubiquituous and the problems it has, i.e. decadency, people less and less able to communicate directly or perform tasks themselves, etc. Really worth reading!
Slashdot Mirror
"And why should it be like an internet protocol?
Well, because they tend to be simple, lightweight and robust, and also because of the difference in philosophy when you compare them to protocols originating in the telco world. Those former are designed in terms of black boxes and the exact way they perform their function first, [...]"
In the last sentence, stike 'former'. I'm referring to the telco protocols, not the internet ones.
Agreed that a runtime can be made platform-specific, but isn't this just another abstraction layer? What is the difference between the runtime and an abstraction layer for GUIs in C++, in terms of cross-platform GUIs?
Of course a runtime is just another abstraction layer. But the thing is that a runtime that provides a virtual platform, shields the program that runs on it from the real host platform. As such, the portability problem is solved separately from the main problem. Remember that I'm not arguing that cross-platform GUIs are impossible in C++, I just say that a language such as C or C++ that has the API of the host platform as its primary toolbox, encourages you to write single-platform applications, and makes it hard(er) to do cross-platform ones.
The strange part is that you've mentioned three of the most famous portable APIs (or, more accurately, API protocols) that are not tied to any language - as examples of why we need portable APIs that are not tied to any language.
That's not strange, that illustrating my point: apparently there is a need for such things. But I think they're following an approach that to me seems needlessly complicated.
And they are, as you said, 800lb gorillas.
That's my objection to them.
And can you elaborate on "put the interface at every conceivable place"?
That's the cause of it as I see it. These protocols allow you to define the interface between any two objects, i.e. they support each and every inter-object communications scheme you can think of supported by every conceivable language. You can export any native object, so to speak, and expose it to the outside world, without limits in functionality.
Can you elaborate on this idea? [data-centric APIs] I like it, but I'm not sure I'm completely following your "thin as possible" line of thinking (what does that mean?)
Well, defining an API in terms of pure data messages encourages you to place the interface between your components in such a way that you need the least amount of different message types, and the smallest number of (interrogation) transactions before doing the actual work.
An API defined in terms of function/method calls that look the same as local ones, doesn't make it seem like much of a problem to have lots and lots of calls from component A to B and from B to A, because it doesn't put the fact that each call must be put through that big remote object layer, firmly in your conscience while developing.
And why should it be like an internet protocol?
Well, because they tend to be simple, lightweight and robust, and also because of the difference in philosophy when you compare them to protocols originating in the telco world. Those former are designed in terms of black boxes and the exact way they perform their function first, and then you look at the information they need to pass between them for each to perform its particular function. Naturally, the resulting protocol will express a lot of how the design and implementation of those black boxes turned out.
But for most internet protocols the intelligence is put more in the data, and the messages themselves tend to get designed in detail before the endpoints are. You basically imagine what each side of the 'wire' theoretically needs to know of the other, and design a way as simple and generic as possible to transmit that information, and you design the black boxes at the endpoints as a next step. Of course this is overstating things a bit in practice, but you get the idea.
The difference is that you're not modeling the protocol to some specific, already designed, detailed endpoint implementation, but to a generic model you've got in your head. Such a protocol will in most cases allow alternative implementations to be done much more easily, and you can see from the number of different implementations for most internet protocols that this is true.
What am I getting at with this? Simply this. Messages (data) are *much* more portable than code libraries; you only need to sort out relatively easy endianness and word size issues, and you're done. So an API defined in those terms will always be much more portable than APIs defined in terms of *functions*, which will always be tied to a particular language, whether that's a native language such as C++, a language that runs on a virtual platform such as Java, or a complex abstract interface description language such as IDL.
If a protocol or API is so complex that the easiest way to port it to a new platform/language is to port a particular code library that implements it to a new platform/language, then it has failed as a protocol, IMHO.
> OTOH, I'd love to see you write a full-blown word processor or a 3D FPS game in HTML and JavaScript.
Exactly. That's why we need something that's much more lightweight, and that's why I said technologies such as XML-RPC are not going to solve the API-as-a-protocol problem.
Something that's a well-balanced rebirth of the X windows protocol, DPS or Apple's Display PDF and HTML + JavaScript combined, that is expressive enough to define much of a GUI in, and at the same time lightweight enough to allow things like games to work.
Oh well, you've got to have dreams, don't you.
From the article:
/do/ want portabilty, you're on your own: you'll have to invent your own abstraction layer in order to achieve it. Obviously, some succeed better than others in that respect, and as he says, it doesn't keep people from trying.
:P), is much better for offering cross-platform services and libraries, simply because the burden does not lie upon each and every individual library developer anymore to create a platform abstraction layer. That only has to be done once, by the runtime.
.NET. But I think the reason why these are so big and ugly is because they want to make it possible to put the interface at every conceivable place. Of course the interfaces will be complex if you do that.
"Q: Standard C++ doesn't support modern programming concepts such as multithreading, distributed computing, components, and persistence. The result is a plethora of proprietary libraries and platform-dependent frameworks that make cross-platform development in C++ nearly impossible. Is Standard C++ still relevant? Which features would you like to see added to the language in the future?
A: Again, these questions arise from an overstated premise. Thousands of companies are routinely writing and shipping cross-platform software written in C++. Claiming that it's "nearly impossible" doesn't change the fact that we've been doing it for years. The one big area I can think of where portability is genuinely difficult is one the question didn't mention -- GUIs. GUI portability is a problem in all languages, unless you give up writing rich GUIs and write only simple and limited ones. Interestingly, despite some languages' attempts to "standardize" cross-platform GUI libraries, the best and most successful solution for cross-platform GUIs is not a code library at all, but HTML."
Well, that proves the point, doesn't it -- HTML + JavaScript is apparently a "language" that people find better suited to define standard, cross-platform GUIs in than C++!
The reason may very well be that C++ GUIs tend to they tie in to too many features of the underlying platform to be portable. If you
It seems that any language that uses a runtime (for HTML+JavaScript, that's the browser; for Java, that's the JVM; for Scheme, that's Emacs
Really, this is not exactly a mind-shattering concept (USCD-Pascal on p-Code anyone?)
Not that the current state of affairs with HTML+Javascript or Java gives much reason to feel content, but I *definitely* still see the point of having a runtime that offers a standard, special-purpose language to define GUIs.
However, I think the API for such a runtime should be viewed more as a data protocol than as a set of language-specific functions to call.
And *that* really applies to more than just GUIs: there really is a need for portable APIs that are not tied to any language these days, if you look at those complex, horrible 800lb monstrosities like Corba, COM or
Why not focus on *data-centric* APIs instead, that are intended to be put where the interface is as thin as possible, and build them as efficient and robust as an internet protocol should be?
If you're thinking of XML now, that may be close, but I really can't see how XML is the most efficient and easy-to-implement way of transmitting trees of attribute/value pairs. It's too difficult and slow to parse, to start using it as a transport for local subsystem calls as well, and contains too much redundancy, such as named close tags.
What the Internet and your local system needs is a good OSI layer 5. Is HTTP + XML really the best thing we can come up with?
A slogan might be handy for a billboard campaign as well.
The law's new name seems to offer a lot more possibilities for that than the old one. Things like "CBDTPA: Consume Broadband only like Digital Televison, or be Punished in America", or "Consumer Broadband Doubles Tariff Per Annum", or "CBDTPA Changes Binary Devices To Perverse Apparatus" spring to mind.
You can probably come up with much better ones.
As others have said earlier, it's probably next to impossible to have 100% compatibility, unless you re-implement all of Word itself.
What is needed more, and what's probably much more practical to achieve, is the ability to *safely edit* Word files!
That means *no* lossy import to suite X, followed by a lossy export to Word again, resulting in a document that doesn't even resemble the original one.
An alternative office suite needs to preserve all the bits and pieces of the Word document it doesn't understand; never mind that they won't look correctly or can't be edited at all.
At least you can then choose for yourself whether you want to live with the limited compatibility. But people won't shout at you anymore for messing up their document when you've corrected some text or filled out a Word form.
Still laughing over that one. Best thing I've read here in a long while!
I know this is a stupid comment. But so what. I just needed to say it.
I agree. Your last remark (the need for server-side toolkits) also hits home IMHO, and I'd suggest a few more things for them:
1. the elements in these toolkits must be able to be defined in terms of server primitives orother elements, using a platform independent special-purpose language. And not only their appearance but also where simple interactions are concerned, such as a 'down' button that moves a slide down and a scrollable view up;
2. the server must be able to receive these definitions from the client itself or to fetch it from an external source on behalf of the client (honor server security by making sure the definition language's scope is limited to the user interface only);
3. the server must be able to cache these elements using unique identifiers by which they can be referenced. These should have two parts: a functional part and an appearance part. Clients specify an element's functional part as a requirement, and its appearance part as a hint, in order for users to be able to provide alternatives (i.e. theme support);
4. a proper encryption and authentication model for the X channel.
This makes the server able to operate more independently, instead of requiring a round trip to the client for every simple operation, making operation over low-security, low-bandwith, high-latency networks such as the internet *much* more practical.
Potentially, this would provide a lot more elegant distributed computing model than the whole mess we have now for exporting user interfaces, with http, html, the DOM, jscript and all those gross hacks that seem impossible to get right if you look at today's browsers.
What do you think?
FWIW, I'd make that boundary equivalent to the boundary between address spaces.
That distiction is good, because programs that share address spaces can alter each others behaviour in arbitrary ways, because they have full access to each others internal variables,
whereas otherwise, each program stays in control of its own behaviour and is free to choose how it reacts to input from the other program.
IOW, communicating with a program through its intended I/O channels, be it files, Unix- or TCP sockets or otherwise, never makes a derivative work, because each program is still free to perform its intended function, which may not be the case for linked objects.
Well, what you can do in the mean time is to wait for processes that can still run to exit gracefully on their own, possibly handling the condition of a malloc() returning NULL.
Of course, because processes tend to wait on each other sometimes, this can still cause nasty deadlocks.
But combined with a number of physical pages that you reserve until you reach OOM condition (cannot free up memory regardless of how hard we try), which even then become available only for processes having uid 0, so that a human root can always get a shell and run kill -9 to break those deadlocks, this could still be an alternative.
That's not the big deal.
I don't care in the least that it's Microsoft and not Apple or Real who succeeded in getting their proprietary format accepted by the electronics manufacturers; the real problem is properietary media formats, period.
The bigger problem is that none of the people in charge (the media industry) has any interest in formats with open specifications, because that would defeat the scheme to move everything to pay-per-view that is taking place:
* closed media formats + anti-reverse engineering laws give control over which players you can use, and
* closed players + anti-circumvention laws give control over how many times you can enjoy the content before having to pay again.
It's just that simple.
Question number one: does the Australian government really want to put the restriction on media that all of its content must be suitable for minors?
/available/ in Australia?
If they recognise published media as one of the ways humans share their culture, do they really intend to lower the intensity of all cultural expression to a level that can be safely handled by children?
I think that many of the most interesting works of art have a serious unsettling effect, even on adults. Perhaps that's what makes them interesting, and what can make peoples life richer after experiencing them.
Of course people should be cautious about the human expressions and experiences a child is ready for. For example, one of the things that I would consider way too intense for children is the amount of manipulative advertising targetted at them. I can hardly imagine a lower and more harmful form of human culture.
I also keep being surprised about how much governments talk about censoring cultural expression from individuals, and so little about limiting targetted expression from companies, who only have responsibilities to their shareholders - but I digress.
Question number two: suppose that the Australian government succeeds in enforcing their restictions on content that is published in Australia, how will they deal with the fact that this will have hardly any effect the content that is
Will they then attempt to make viewing certain content illegal, if they find out they cannot control what people publish in less restrictive countries, and that they cannot control what makes it into Australia, because the objects transported across their borders are pure bitstreams, which are not recognisable as human expressions of any type during their transport?
Only if the internet would indeed work by a form of manual mirroring, with little dwarfs feverishly reading all internet content from abroad and re-publishing it on domestic servers, then national censorship would work.
It's just a pity that a lot of politicians' imagination does not seem to be capable to extend much beyond this idea. Who knows, it may just be the lack of exposure to human culture that has limited the development of their imagination...
Sounds nice in theory, but I think that the biggest stumbling block for such interoperability is that the file format and the semantics of the data stored in it, are tied incredibly tight to the model used in Word to represent documents, and probably just as much to Word's particular implementation of it.
.doc file contains the value of the variable FooBar' where FooBar is something entirely implementation-specific.
Think problems like 'the third octet of the
The people who developed Word had no incentive at all to make things more abstract, because Word's whole business model is mostly based on the idea that Word documents can only be used reliably with Word.
What we need instead is a better document editing paradigm and a portable format that goes with it. We can only be worse than Word itself as long as we try to imitate it. And there can be no conversion filter that's actually usable without imitating Word's document models.
It seems these people are trying to make damn sure you'll become painfully aware of the need for a browser that does all those playful CSS/DHMTL things.
Using NS4, their pages come out *completely* garbled.
But I won't switch anywhere soon. Why not? Because I don't *want* an application that's supposed to be simply a client for *simple, transaction based UIs*, that is bigger than my unix kernel and X together.
I think this situation is a damn shame, and proves to me the failure of the whole HTML concept. "Logical/structural document layout" instead of physical layout may be nice in theory, but a. what's the use if it can't even auto-generate tables of contents or anything that'd make structural markup actually *useful*, and b. the idea that every type of UI can follow a document model, and that every document can follow some hierarchical content model was an rare case of hybris, if you ask me.
It's probably OK for scientific papers, which all have *very* similar structure. But you need a *ridiculous* amount of complexity to try and squeeze every application UI in the same model. And it shows.
I think we should do something else; create a UI description language that's NOT a document markup (HTML), not a pre-downloaded 'interactive' animation script (Flash), not a general-purpose programming language (Java), and not a rigid, low-level protocol like X; rather a network-transported language in which you can describe widgets and simple interactions between them in terms of lower-level widgets and UI elements. Think 'interactive' postscript (but with infix notation). Or *something*.
Then we can finally push the UI, *only* the UI, but as much of it as possible to the client, and have clients keep an open (tcp) connection to the application that can be as stateful as it likes. Whatever.
But it should be possible to finally find a good middle ground between X and HTTP+HTML. There's *got* to be a way.
Any thoughts? Does anybody know of such a project?
From the looks of it, this seems more than a bit serious. Would perhaps being dependent to a large extent on 'downstream' maintainers (who take care of the packaging) be part of the problem?
Perhaps people should encourage 'upstream' developers more to accept debian package building specs as part of their base tree.
As a developer, you still need to know a bit of how the packaging system works, but it would probably make you feel more responsible if it's included in your own releases.
Perhaps I'm way off and this all has nothing to do with it though...
Depends on your interfaces, of course. If you want to bind the modules together by having them freely call each others functions, this can and probably will become a debugging nightmare.
However, for those cases where you'd already go for a multiprocess design, using a clean protocol that's spoken between the modules, it can be quite a good idea to exploit the simple fact that some languages are better at some things than others.
Eg. my current project, OpenRADIUS has a C core that does low level packet handling, job scheduling, etc., and a module that happens to be written in Perl to easily deal with simple and more complex formatted ASCII tables.
If I would have had to write that module in C as well, it would *definitely* have taken me a lot more time.
I don't understand why you think precedence is something that's a "confusing" concept in general. I was taught that multiplication comes before addition in primary school...!
Also, because these rules don't tend to change in a language, I fail to see how relying on precedence makes code hard to maintain or easy to break ("brittle"). It won't break spontaneously, if that's what you mean. Somebody who does not know the language's rules has to come along and edit your code first.
If you're using a language for expressions, you've got to know the rules. When using any language with infix expressions, the precedence rules just belong to the rules that you're required to know, just as some other essential grammar rules for that language.
The only situation where you run into trouble is if you either believe that knowning grammar at all is optional, or that precedence rules don't belong to an infix expression language's grammar, and I don't think you can make a good case for either.
Hm. I'd say that there should be a very explicit question answered by the luser before a "document" can even make a "Click here" button (with a nasty action resulting from it) appear at all.
It should only be possible to cross the border between 'data' and 'program' after the user is presented with a very clear message about what he/she is about to do: allowing a new *program*, that's embedded in a *document*, to really do anything it wants with his/her computer.
Any attempt at stopping these worms without enforcing that border is futile, IMHO.
Well, ifdefs may not always be the right solution, but why not have a fork
just at the platform level, instead of the whole tree? e.g. We'd have
arch/alpha, arch/hugealpha, arch/x86, arch/bigx86, arch/embedx86...
If Linux didn't need a fork even when adding the 64-bit architectures, surely it
should be possible to keep things like differently optimized memory managers
in the same tree?
*Grin* Perhaps Jobs' thoughts wandered off during the meeting and remembered a GUI design discussion with Steve W. about whether to use single- or double clicks for certain actions... So at one point he suddenly shouted aloud: 'I want _one_ click!'
The rest is history.
I must admit, the guy is consistent in what he wishes...
What if the code morphing software authors (Hi Linus!)
decided to 'extend' the X86 base instruction set just a bit, like 3DNow, MMX and so forth, only not to
provide graphics acceleration, but to provide 'hints' to the code morphing software?
In my imagination, there need be just a few of those extra instructions, and a clever compiler can stick them in to provide
the code morpher with some difficult-to-find but static dependancy/ordering information. (I.e. potentially anything not needing run-time statistic gathering).
If these hints are absent, the morpher just does its regular job. Now, good idea or not?
What kind of thing do you have in mind when you refer to 'native Wintel networking'...? Arpa's TCP/IP??? IBM's LanManager (you know, the thing with the shares that MS calls 'the core of microsoft networking')? Both things were created
before windows even existed (but of course you already know that). So what exactly _do_ you mean?
Erm... may I point out that Apache is, although not
multithreaded in the sense of multiple threads in
one process space, a multiprocess webserver?
That means any SMP is taken full advantage of!
I often find those buzzword-deep remarks about multithreading
rather annoying, as the only reason IMHO it's hyped so much
these days is because NT is so bad at IPC and creating processes.
Also, what buggers me is the silly idea in the article
that Apache would need to fork() for each request. This is nonsense, as
you can configure as much pre-spawned servers as you want! So the reason why they suppose why apache whould perform worse than a multithreaded server escapes me. As to CGI, forget it, that _does_ need a fork(),execve() for each request. Rather, go fastcgi...! This way, application services can be prespawned too and reused between requests. Just my Hfl. 0.05...
Unless those robots have the three (four) laws that Asimov envisions ;-), which are:
(I wonder from who else you got that 'positron' idea
1. Do not harm any human, either by direct action or by neglegence;
2. Obey any human, except if the resulting action would violate law 1;
3. Protect yourself, except if the resulting actions would violate either law 1 or 2.
Asimov really goes to great depths exploring possible future societies that have this kind of robots; from their inception, people struggling to accept them, their
odd behaviour, etc. But to stay on topic, he also wrote a book (it's called Children of the Sun, or something) about
a society in which these robots are ubiquituous and the problems it has, i.e. decadency, people less and less able to communicate directly or perform tasks themselves, etc.
Really worth reading!