Good argument, for GUI systems
on
Is UNIX An OS?
·
· Score: 1
The usual CS explanation of what an OS is involves notions of a central core of functionality that mediates interaction between applications and the hardware, and between each other. It provides the services that the applications require.
Now, if the only applications that you're interested in are (for want of another example) GNOME applications, you could argue that the services that they require include the gtk widget set, the bonobo system, whatever the new, super-duper printer handling system will be. These applications all expect to be able to follow links and open help files with some sort of system browser.
It's still Unix, though. Unix is much more than just the kernel. Unix is the whole shooting match.
I can't say that I disagree with any more than the thrust of the first paragraph, and no, I haven't had a close look at C#.
You really don't need to write your own header files to have a modularised language. Have a good look at Eiffel. One of it's operating philosophies is "never get a person to do something that the computer is capable of doing for itself". Extracting the interface specifications for an object from it's implementation (code) is one of those things. I'm really, really, over writing all of my method/function prototypes twice in C and C++.
Your argument requires that the _only_ players in existence will be licenced, and perform this marking. DeCSS shows (by analogy with DVDs) that secure unfriendly clients are a myth. Users like to choose their own players, and player manufacturers like to sell players that the users choose.
Even if opened with a restrictive licence like the Sun community licence, it would be a great thing for anyone who doesn't use one of the existing platforms: Linux on non-intel, *BSD on anything. (Linux emulation is all well and good, but native would be nicer.)
I agree that Java is fatter than is needed on a terminal, which is why I don't understand why you've gone from there to "do a lot of computation per event...locally". That sounds as though you _want_ fatness. The best place for lots of computation is as close to the data as you can get, which is on the server. The data transfer for any resulting visual effects is usually tiny by comparison.
You don't need to design a new lightweight terminal system: just re-discover X. I can't believe that you left it out of your list of options. Dedicated X terminals can be built on systems that would be considered puny by today's PC standards. During the early nineties, the group I worked with had a lab of 20 or so X terminals, NCDs and Labtams. The Labtams were the best, with snappier GUI response than the MIPS and Sun workstations that were also on the net. These machines had a 16MHz i960 and 8M of RAM. No special graphics hardware, but hand-tuned blit code on the i960.
What is it that you feel X _doesn't_ give you that another "thin terminal" protocol might?
The trouble is that a "CensorMate3000" would probably do that, even though both "shit" and "fuck" have been approved by the courts as acceptable words.
When did we decide that a bunch of pathological puritans should be our social yardstick?
I can't believe that there are so many paper apologists among slashdotters! Personally I could probably count the documents I've committed to paper in the last five years on one hand. Paper is just too slow, documents (source code especially) just too big, and you can't do searches or hit hyperlinks. With modern graphics cards and 500MHz processors, even the "flipping pages" argument doesn't hold water: the computer can keep up with my visual cortex now.
I'll second the Trackpoint comment. I was getting shoulder strain in my mouse-arm until I got this beastie. It's brilliant. Fingers never leave the home row. The IBM keys feel nice too, but the clicking took a little while to get used to. I use this keyboard around fourteen hours a day, with no problems or fatigue.
About the only serious problem is that I'm momentarily stumped whenever I have to use a regular mouse.
This is *partially* good news
on
Java for EGCS
·
· Score: 1
Last time I looked, gcj compiled from bytecode, rather than source, so I can't see that you loose any cross-platform compatability.
For example, I currently use a command-line network tool that was written in Java just so that it would "run everywhere". At the moment, I run it under the JDK, but if I could compile it to a native binary, I wouldn't need to have the JDK mapped in all the time.
Slashdot Mirror
The usual CS explanation of what an OS is involves notions of a central core of functionality that mediates interaction between applications and the hardware, and between each other. It provides the services that the applications require.
Now, if the only applications that you're interested in are (for want of another example) GNOME applications, you could argue that the services that they require include the gtk widget set, the bonobo system, whatever the new, super-duper printer handling system will be. These applications all expect to be able to follow links and open help files with some sort of system browser.
It's still Unix, though. Unix is much more than just the kernel. Unix is the whole shooting match.
I can't say that I disagree with any more than the thrust of the first paragraph, and no, I haven't had a close look at C#.
You really don't need to write your own header files to have a modularised language. Have a good look at Eiffel. One of it's operating philosophies is "never get a person to do something that the computer is capable of doing for itself". Extracting the interface specifications for an object from it's implementation (code) is one of those things. I'm really, really, over writing all of my method/function prototypes twice in C and C++.
Your argument requires that the _only_ players in existence will be licenced, and perform this marking. DeCSS shows (by analogy with DVDs) that secure unfriendly clients are a myth.
Users like to choose their own players, and player manufacturers like to sell players that the users choose.
Even if opened with a restrictive licence like the Sun community licence, it would be a great thing for anyone who doesn't use one of the existing platforms: Linux on non-intel, *BSD on anything. (Linux emulation is all well and good, but native would be nicer.)
I agree that Java is fatter than is needed on a terminal, which is why I don't understand why you've gone from there to "do a lot of computation per event...locally". That sounds as though you _want_ fatness. The best place for lots of computation is as close to the data as you can get, which is on the server. The data transfer for any resulting visual effects is usually tiny by comparison.
You don't need to design a new lightweight terminal system: just re-discover X. I can't believe that you left it out of your list of options. Dedicated X terminals can be built on systems that would be considered puny by today's PC standards. During the early nineties, the group I worked with had a lab of 20 or so X terminals, NCDs and Labtams. The Labtams were the best, with snappier GUI response than the MIPS and Sun workstations that were also on the net. These machines had a 16MHz i960 and 8M of RAM. No special graphics hardware, but hand-tuned blit code on the i960.
What is it that you feel X _doesn't_ give you that another "thin terminal" protocol might?
The trouble is that a "CensorMate3000" would probably do that, even though both "shit" and "fuck" have been approved by the courts as acceptable words.
When did we decide that a bunch of pathological puritans should be our social yardstick?
I can't believe that there are so many paper apologists among slashdotters! Personally I could probably count the documents I've committed to paper in the last five years on one hand. Paper is just too slow, documents (source code especially) just too big, and you can't do searches or hit hyperlinks. With modern graphics cards and 500MHz processors, even the "flipping pages" argument doesn't hold water: the computer can keep up with my visual cortex now.
I'll second the Trackpoint comment. I was getting shoulder strain in my mouse-arm until I got this beastie. It's brilliant. Fingers never leave the home row. The IBM keys feel nice too, but the clicking took a little while to get used to. I use this keyboard around fourteen hours a day, with no problems or fatigue.
About the only serious problem is that I'm momentarily stumped whenever I have to use a regular mouse.
Last time I looked, gcj compiled from bytecode, rather than source, so I can't see that you loose any cross-platform compatability.
For example, I currently use a command-line network tool that was written in Java just so that it would "run everywhere". At the moment, I run it under the JDK, but if I could compile it to a native binary, I wouldn't need to have the JDK mapped in all the time.