The ultimate would be a VM written in the same bytecode that it interprets.
Squeak actually has this. It's pretty nifty: a VM for Smalltalk written in Smalltalk, so that it can self-host. It's slow, but it works. The Smalltalk is translated into C and then compiled natively, of course, to build a runtime, but the reason why this was done was to aid the developers of the system in debugging. (They are Smalltalk zealots and do not like messing with icky C.)
This smacks very strangely of the secret "Bilderberg" meetings wherein foreign policy is decided behind locked and very heavily guarded doors without public input or scrutiny. It really is "Us" against "Them".
Not so fast. If you can hear it, you can also detect a watermark in it, and that's what the RIAA is hoping to require soundcard manufacturers to do. Imagine wiring up your sound card to record from line in, hitting the record button and getting a dialog box saying you can't record what's coming over the wire due to the presence of a copyright watermark. That's what they're aiming for.
ah, but what if you emulate the ROM, i.e., provide implementations of the functions contained in it? Apple will probably sue you but it can theoretically be done.
Because Darwin does not add much value to the Unix/BSD world from an application developer's standpoint, the really key components of OS X are the GUI and Openstep environment (Aqua, et al.) which are closed source. Therefore, most Linux users approach OS X as a closed, proprietary system with a few open components.
It will be interesting to see how far GNUstep gets in emulating OS X (and to watch Apple turn loose the attack lawyers once they're close).
Flamey goodness indeed. Turning to mackido.com for objectivity in computer innovation is a bit like asking the Taliban for an objective stance on women's rights.
The ironic thing about that statement is, back in the early nineties when IBM still thought they were the Evil Empire, they codenamed a version of OS/2 "Farengi", their justification being that the Farengi get what they want no matter what the means.
Your troll nature has been revealed for what it is. You lose.
Re:Mozilla Project Success; Mozilla Browser Failur
on
Mozilla Relicensing
·
· Score: 2
Mozilla is more corrent, more stable, and faster than Konqueror and Opera. The constant whining of the KDE sycophant class cannot change this fundamental fact. Mozilla is designed to render HTML and XML documents, and to expose the DOM API to programs, according to W3C specifications. Konqueror is designed to increase the zeal of its sycophants. Both projects appear to be successful.
I am not sure if your statements re: Konqueror are accurate. I think that Konq exists mainly to provide an exact counterpart to Internet Explorer for KDE: an "integrated-with-the-desktop" Web browser.
I do not agree with this idea. More importantly I do not want to subject my desktop to the kinds of bloat that KDE and GNOME represent. Hence my reasons for not using Konq and for using Mozilla; if I were a KDE user I'd give it a go.
I dunno about real but I've had no problems viewing Flash sites. Mozilla even handles reasonably complex java well, if I use the plug-in from JRE 1.3.1. Which is much, much more than I can say for Netscape 4.x releases. If I keep it open for hours and hours, eventually it will act funny, segfault and crap out but it lasts longer, on average, than IE ever would.
Nearly all Web sites that render properly on IE (barring those that only include IE-specific JavaScript, or sniff for browser make and model and reject Netscape 6/Mozilla) look fine on Mozilla.
For Windows and Linux, at least, Mozilla is a very usable, solid browser for the Real World.
But the US is still somehow tangentially involved. B'nai B'rith represents the interests of the state of Israel. Because the United States is on Israel's side in the Middle Eastern conflict, it would seem that B'nai B'rith's actions in other countries will reflect what happens here.
(Actually their work here should be easy... they have all our politicians in their pocket...)
Looking for a fast, portable, free-as-in-speech, object-oriented language? Try Squeak, a wonderful smalltalk implementation. It's great. I've been playing with it quite a bit myself, and have been very pleased with it.
The DMCA was passed to bring the US into compliance with WIPO regulations. It wasn't really just our idea. It WILL happen worldwide unless we can win the battle here.
Today's advanced Emacsen have toolbars and menus to help the "average" user. Of course I find them cumbersome and end up using the key commands anyway...
I was referring more to an architecture like that of Emacs, not necessarily the same exact interface.:)
"I saw this KDE thing and it looks just like a Mac. Can we use it on our linux box?"
I obliged him then, but these days we're running OpenBSD GUI-less. I think it's safer to keep X off a server.
Still, I think KDE is still a few steps ahead of GNOME, and headed in a better direction overall. But give me command prompts, pipes, and Scheme hacks any day.:)
I beg to differ. The COM code I have seen quite remarkably resembles instantiation of and passing messages to objects in an object-oriented paradigm. Let's not forget the giveaway: the acronym itself. Component Object Model. Microsoft has been a big booster of the "object-orientedness" of its component architecture.
Unix "programs" have standard interfaces as well. Data is piped via stdin and returned via stdout. The input data is expected in a certain format. The output data is returned in a predefined format.
Hmmm.. sounds like an interface to me!
Yes, but that interface is both trivially simple and completely transparent. It makes coding and debugging the "components" and the applications which use them much faster and easier. It also allows you to fit the pieces together in new and intriguing ways. You lose a bit of flexibility at the component level (only one simple interface) but gain flexibility when your scope is the overall application.
COM is nothing more than a standard which defines the call stack for any "components" function call.
Most object-oriented paradigms are simply this: they simply associate this chunk of data with that bundle of operations. This is usually veiled very carefully to force the programmer to think in terms of magical function-data aggregates ("objects") instead of seperate data and function calls (which is how computers work, at least those using von Neumann architecture).
This is not necessarily a disadvantage in itself; sometimes it's desirable. Games and GUI widgets are best expressed in object-oriented style, for instance. However, the disadvantages of the COM approach (bloat, complexity hell, vendor lock) make it a mess to deal with.
Those that haven't used COM in a real-world environment shouldn't knock it.
I have used it in a real world environment. And there are times when I would have much rather simply piped my data through a perl script.
Yes, this is true. Perhaps I should have said "it's a waste". You need a far more powerful computer today to do the same damned things you did with a computer 20 years ago! Why? It makes no sense.
I think Microsoft is trying to have its cake and eat it too: it's trying to create a powerful extensible architecture while still keeping the end user (commonly abstracted as "Joe User", "Joe Six-Pack" or "my grandma") in his little sandbox.
On the one hand you have power, and on the other you have a drool-proof interface. You can't really have both at the same time. If you want to take advantage of the power, you're going to have to steepen the learning curve a bit. If you want a drool-proof interface, you may as well use a typewriter instead.
Which is not to say that the software needs to be abstruse and inaccessible except by a cabal of experts. I'm saying that the "sit down and start working" modality is an unattainable goal with most sophisticated application software. (No, Office doesn't achieve it either. As someone who's had to train and retrain his mother and sister in Microsoft Word, I know what I'm talking about.) What should be done instead of focusing single-mindedly on asymptotically approaching this holy grail of ease of use is to make the learning process as painless as possible. It may even be fun.
This is where projects like Squeak come into play. Squeak is basically a laboratory for new ideas in application design. I think that it will eventually lead to some commercial-grade applications for various operating systems that offer all users a degree of flexibility and control that wasn't thought possible in the Microsoft/Apple paradigm.
Oh, and Squeak is hella fun to play with, even if you're not a programming superstar.:)
I'm reminded of a cartoon wherein a businessman is revealing a "New Approach" to sending mail. He yanks off the veil and reveals... a typewriter (the old Underwood variety), an envelope, and a stamp.
If all you want to do is type a damn letter, there's your solution. I find it shameful that so many interesting machines are conscripted into doing nothing but boring tasks.
Slashdot Mirror
Squeak actually has this. It's pretty nifty: a VM for Smalltalk written in Smalltalk, so that it can self-host. It's slow, but it works. The Smalltalk is translated into C and then compiled natively, of course, to build a runtime, but the reason why this was done was to aid the developers of the system in debugging. (They are Smalltalk zealots and do not like messing with icky C.)
This smacks very strangely of the secret "Bilderberg" meetings wherein foreign policy is decided behind locked and very heavily guarded doors without public input or scrutiny. It really is "Us" against "Them".
Not so fast. If you can hear it, you can also detect a watermark in it, and that's what the RIAA is hoping to require soundcard manufacturers to do. Imagine wiring up your sound card to record from line in, hitting the record button and getting a dialog box saying you can't record what's coming over the wire due to the presence of a copyright watermark. That's what they're aiming for.
... good to see somebody getting some serious use out of that trusty old CPU architecture, anyway :)
That mutant healing factor should come standard on all server hardware, I think.
ah, but what if you emulate the ROM, i.e., provide implementations of the functions contained in it? Apple will probably sue you but it can theoretically be done.
Because Darwin does not add much value to the Unix/BSD world from an application developer's standpoint, the really key components of OS X are the GUI and Openstep environment (Aqua, et al.) which are closed source. Therefore, most Linux users approach OS X as a closed, proprietary system with a few open components.
It will be interesting to see how far GNUstep gets in emulating OS X (and to watch Apple turn loose the attack lawyers once they're close).
Flamey goodness indeed. Turning to mackido.com for objectivity in computer innovation is a bit like asking the Taliban for an objective stance on women's rights.
The ironic thing about that statement is, back in the early nineties when IBM still thought they were the Evil Empire, they codenamed a version of OS/2 "Farengi", their justification being that the Farengi get what they want no matter what the means.
I think that's how Scooby-Doo says it.
Junior high students at least go to the library and do a little research.
This is a trull. Ignore it.
Moz runs quite acceptably on my 266MHz laptop.
Your troll nature has been revealed for what it is. You lose.
I am not sure if your statements re: Konqueror are accurate. I think that Konq exists mainly to provide an exact counterpart to Internet Explorer for KDE: an "integrated-with-the-desktop" Web browser.
I do not agree with this idea. More importantly I do not want to subject my desktop to the kinds of bloat that KDE and GNOME represent. Hence my reasons for not using Konq and for using Mozilla; if I were a KDE user I'd give it a go.
On linux Mozilla starts up usually in under 10 seconds. Possibly under 5 if it's still lingering in the disk cache.
.... 'nuff said.
Under Windows? mozilla -turbo
I dunno about real but I've had no problems viewing Flash sites. Mozilla even handles reasonably complex java well, if I use the plug-in from JRE 1.3.1. Which is much, much more than I can say for Netscape 4.x releases. If I keep it open for hours and hours, eventually it will act funny, segfault and crap out but it lasts longer, on average, than IE ever would.
Nearly all Web sites that render properly on IE (barring those that only include IE-specific JavaScript, or sniff for browser make and model and reject Netscape 6/Mozilla) look fine on Mozilla.
For Windows and Linux, at least, Mozilla is a very usable, solid browser for the Real World.
But the US is still somehow tangentially involved. B'nai B'rith represents the interests of the state of Israel. Because the United States is on Israel's side in the Middle Eastern conflict, it would seem that B'nai B'rith's actions in other countries will reflect what happens here.
(Actually their work here should be easy... they have all our politicians in their pocket...)
Looking for a fast, portable, free-as-in-speech, object-oriented language? Try Squeak, a wonderful smalltalk implementation. It's great. I've been playing with it quite a bit myself, and have been very pleased with it.
The DMCA was passed to bring the US into compliance with WIPO regulations. It wasn't really just our idea. It WILL happen worldwide unless we can win the battle here.
Today's advanced Emacsen have toolbars and menus to help the "average" user. Of course I find them cumbersome and end up using the key commands anyway...
:)
I was referring more to an architecture like that of Emacs, not necessarily the same exact interface.
My Mac-using boss:
:)
"I saw this KDE thing and it looks just like a Mac. Can we use it on our linux box?"
I obliged him then, but these days we're running OpenBSD GUI-less. I think it's safer to keep X off a server.
Still, I think KDE is still a few steps ahead of GNOME, and headed in a better direction overall. But give me command prompts, pipes, and Scheme hacks any day.
So do I. :)
Of course we're living in an age where butter knives mean weapons charges... such is the path of ignorance of the tools we use.
I underestimated your troll nature, Mr. AnCow. I shan't make that mistake again.
I beg to differ. The COM code I have seen quite remarkably resembles instantiation of and passing messages to objects in an object-oriented paradigm. Let's not forget the giveaway: the acronym itself. Component Object Model. Microsoft has been a big booster of the "object-orientedness" of its component architecture.
Yes, but that interface is both trivially simple and completely transparent. It makes coding and debugging the "components" and the applications which use them much faster and easier. It also allows you to fit the pieces together in new and intriguing ways. You lose a bit of flexibility at the component level (only one simple interface) but gain flexibility when your scope is the overall application.
Most object-oriented paradigms are simply this: they simply associate this chunk of data with that bundle of operations. This is usually veiled very carefully to force the programmer to think in terms of magical function-data aggregates ("objects") instead of seperate data and function calls (which is how computers work, at least those using von Neumann architecture).
This is not necessarily a disadvantage in itself; sometimes it's desirable. Games and GUI widgets are best expressed in object-oriented style, for instance. However, the disadvantages of the COM approach (bloat, complexity hell, vendor lock) make it a mess to deal with.
I have used it in a real world environment. And there are times when I would have much rather simply piped my data through a perl script.
Yes, this is true. Perhaps I should have said "it's a waste". You need a far more powerful computer today to do the same damned things you did with a computer 20 years ago! Why? It makes no sense.
:)
I think Microsoft is trying to have its cake and eat it too: it's trying to create a powerful extensible architecture while still keeping the end user (commonly abstracted as "Joe User", "Joe Six-Pack" or "my grandma") in his little sandbox.
On the one hand you have power, and on the other you have a drool-proof interface. You can't really have both at the same time. If you want to take advantage of the power, you're going to have to steepen the learning curve a bit. If you want a drool-proof interface, you may as well use a typewriter instead.
Which is not to say that the software needs to be abstruse and inaccessible except by a cabal of experts. I'm saying that the "sit down and start working" modality is an unattainable goal with most sophisticated application software. (No, Office doesn't achieve it either. As someone who's had to train and retrain his mother and sister in Microsoft Word, I know what I'm talking about.) What should be done instead of focusing single-mindedly on asymptotically approaching this holy grail of ease of use is to make the learning process as painless as possible. It may even be fun.
This is where projects like Squeak come into play. Squeak is basically a laboratory for new ideas in application design. I think that it will eventually lead to some commercial-grade applications for various operating systems that offer all users a degree of flexibility and control that wasn't thought possible in the Microsoft/Apple paradigm.
Oh, and Squeak is hella fun to play with, even if you're not a programming superstar.
I'm reminded of a cartoon wherein a businessman is revealing a "New Approach" to sending mail. He yanks off the veil and reveals... a typewriter (the old Underwood variety), an envelope, and a stamp.
If all you want to do is type a damn letter, there's your solution. I find it shameful that so many interesting machines are conscripted into doing nothing but boring tasks.