There is a difference between software, e.g. OpenOffice, and interfaces, e.g. OpenDocument. It is true that this move by Massachussetts closes down the market on interfaces used to publish electronically. Honestly, I find that a bad thing on its own, and would prefer if Massachussetts had made a broader definition of "open formats". Anyway, the interface design is a small fraction of the overall intellectual work involved. The market for the much larger portion of intellectual work on software is left wide open by this move.
In particular, MICROSOFT CAN SUPPORT OPENDOCUMENT if they wish. This move does not rule out Microsoft from use in Massachussetts; it simply insists that they behave in a congenial way if they are to be used by government offices. Whether MS supports OpenDocument or not, I am a happy camper -- I like commercial software companies in general, and I simply dislike tactics such as proprietary file formats.
It's analagous to picking an official language for a government. Instead of having each office pick its own language locally, every US public office is required to publish in English. Similarly, now Massachussetts offices must electronic-publish in OpenDocument and PDF.
Notice that it is impossible to change all software. So long as tricky rules are around, there will be software that does not follow the rules correctly.
There are things you can do in your own software, such as religiously avoiding re-implementing things you know are tricky. For that matter, however, it's good to religious avoid re-implementing anything anyway, tricky or not.
An additional lesson, though, is that your perfect software may end up needing to interoperate with software that screws it up. If you want robust software, it had better not insist that the other software it communicates with can be synchronized to the second with your local computer and can furthermore deal with 61-second minutes.
Garbage-collection and run-time type safety are both very nice. From the sound of things, you can even have a direct pointer to something in someone else's address space. Plus, the security model sounds much better than Unix's.
In fact, it has everything on my wish list for a good OS except for automatic checkpointing the way EROS has. It's just too bad the thing costs $150....
EROS: security differences are the key
on
The End of Unix?
·
· Score: 1
Agreed completely, EROS is way cool. Now, the orthogonal persistence could conceivably be added to a Unix kernel without changing anything that is user visible--thus it would still be basically Unix, except that you could do things like turn off the computer, turn it back on, and have your desktop up in front of you again in just a minute or two. This is an awesome feature, and it's one I hope more well-developed operating systems start making available.
The security differences, however, are deep and pervasive. Unix security works well for seperating users from each other, and for letting them safely use resources provided by an administrator. However, it makes it darned hard for users to collaborate with each other. Imagine you want to use A's compiler to compile B's program and save it in a file owned by C. A, B, and C have agreed to this. The compiler should only be able to access its own files, and the program, and the destination file.
This is a nightmare for Unix. I suppose you'd have to rewrite the compiler as a server and talk to it over sockets. But on EROS, if I understand right, a standard compiler would work just fine. Instead of giving an EROS compiler file names, you'd give it handles (capabilities) to the two files in question, and the compiler wouldn't be allowed to access any other files except for its own. Voila--users communicating, easily, without exposing themselves the way setuid or setgid would.
Communicating via the filesystem and via filenames is extremely ubiquitous in Unix. Once this goes to something better, IMHO it won't really look like Unix any more.
Both of these guys are still at it. They did *not* just spout some interesting ideas and then go back to hacking. They are busy putting in the 99% persperation that can transform "gee, what a clever idea" into "holy maceral, they just changed the world".
Specifically, Douglass Engelbert is working on making his idea of corporation/computer synergies come to life, and he's trying to explain to people just what the heck he's talking about (which to hear him, most people still don't get). Alan Kay is working on making his Dynabook goal finally happen, via the Squeak project (www.squeak.org). His original goals outstripped hardware of the 70's could do, but nowadays that is no longer an issue. In fact, when his group first announced the project a few years ago, they titled their paper "Back to the Future". Do they sound slightly condescending to the intervening decades of hacking? Well, they deserve to be!
Overall, let's not go by what the trade rags say is "hot". Trade rags are designed to give people warm fuzzies, not to excite them about difficult goals for computers in society.
explicit package system, intead of preprocessor tricks
various standardized API's that will be cool if they are ever widely deployed
However, there is so much more available in other languages, for instance:
numbers, characters, and strings are objects
dynamic typing is an option
decent type systems, especially wrt generics
decent library of classes; largely this is due to typing problems
Maybe Java will at least get people thinking about the languages which set the context for so much of their work. If you aren't worried about applets, then, for many programming domains, languages like Lisp and Smalltalk give you the same benefits that Java does, plus more, and plus they have stable, mature implementations.
and it's not that much code to start with...
on
V2 OS
·
· Score: 1
...so porting versus rewriting isn't that big of a deal.
Actually, you can just write a gcc machine specification on a supported machine, cross-compile gcc and whatever else you need for the new machine, and then figure out a way to initially load your new executables. No assembly required, except for the poor sap that makes the gcc spec work for the new machine.
Uhh, code bloat, yes. But instability?? No way. It's WAY easier to screw up using assembler than using C, and in turn it's way easier to screw up using C than using some higher-level language like Lisp or Smalltalk.
I've been typing on Dvorak for about a year, and the huge benefit is *comfort*, not speed.
Sure, dvorak certainly faster. But it's not faster by more than a factor of 1.5-2 times. And furthermore, most people are far below the speed limit that either layout imposes; they'd benefit more from taking some typing lessons than they would from learning a new layout.
But even so, switch to dvorak. You're hands will love you. And, it only takes about a month to do it. What's a month, compared to however much time you plan to spend using computers in your life?
And incidentally, it's *not* that hard to remain able to use both kinds of keyboard layout. I certainly can type okay on Qwerty, though it feels slow and awkward....
In Windows98, just look in the Keyboard control panel. In Linux, do "loadkeys dvorak". On Macs, download a dvorak layout and add it to some folder somewhere.
Can we please stop this worshiping of GUIs as being the defining characteristic of modern software? I've even heard people complain that some technique or another is useless because it won't work on "real" code--ie, code that is all GUI and no substance.
just to quickly name a few? The important parts of these things don't have a GUI involved. Coding GUIs is just one general skill.
The really important things aren't changing that fast. In fact, from the little time I do spend with older guys, I'm reminded of just how much of whippersnappers *haven't* caught on to, that *they* knew decades ago.
Can we please stop this worshiping of GUIs as being the defining characteristic of modern software? I've even heard people complain that some technique or another is useless because it won't work on "real" code--ie, code that is all GUI and no substance.
But what about:
- satellite control - Internet search engines - medical devices
just to quickly name a few? The important parts of these things don't have a GUI involved. Coding GUIs is just one general skill--a relatively easy one when you think about stuff like the above.
Can we please stop this worshiping of GUIs as being the defining characteristic of modern software? I've even heard people complain that some technique or another is useless becuase it won't work on "real" code--ie, code that is all GUI and no substance.
Can we please stop this worshiping of GUIs as being the defining characteristic of modern software? I keep hearing people talk about GUI skills as being skills of the new day, and I keep hearing people complain that some technique or other is useless becuase it doesn't work with GUI code.
The fact is, if the GUI is really a significant part of a program, then either:
1) The program isn't that intellectually challenging, as it's just a bunch of GUI code.
Slashdot Mirror
There is a difference between software, e.g. OpenOffice, and interfaces, e.g. OpenDocument. It is true that this move by Massachussetts closes down the market on interfaces used to publish electronically. Honestly, I find that a bad thing on its own, and would prefer if Massachussetts had made a broader definition of "open formats". Anyway, the interface design is a small fraction of the overall intellectual work involved. The market for the much larger portion of intellectual work on software is left wide open by this move.
In particular, MICROSOFT CAN SUPPORT OPENDOCUMENT if they wish. This move does not rule out Microsoft from use in Massachussetts; it simply insists that they behave in a congenial way if they are to be used by government offices. Whether MS supports OpenDocument or not, I am a happy camper -- I like commercial software companies in general, and I simply dislike tactics such as proprietary file formats.
It's analagous to picking an official language for a government. Instead of having each office pick its own language locally, every US public office is required to publish in English. Similarly, now Massachussetts offices must electronic-publish in OpenDocument and PDF.
Notice that it is impossible to change all software. So long as tricky rules are around, there will be software that does not follow the rules correctly.
There are things you can do in your own software, such as religiously avoiding re-implementing things you know are tricky. For that matter, however, it's good to religious avoid re-implementing anything anyway, tricky or not.
An additional lesson, though, is that your perfect software may end up needing to interoperate with software that screws it up. If you want robust software, it had better not insist that the other software it communicates with can be synchronized to the second with your local computer and can furthermore deal with 61-second minutes.
Garbage-collection and run-time type safety are both very nice. From the sound of things, you can even have a direct pointer to something in someone else's address space. Plus, the security model sounds much better than Unix's.
In fact, it has everything on my wish list for a good OS except for automatic checkpointing the way EROS has. It's just too bad the thing costs $150....
Agreed completely, EROS is way cool. Now, the orthogonal persistence could conceivably be added to a Unix kernel without changing anything that is user visible--thus it would still be basically Unix, except that you could do things like turn off the computer, turn it back on, and have your desktop up in front of you again in just a minute or two. This is an awesome feature, and it's one I hope more well-developed operating systems start making available.
The security differences, however, are deep and pervasive. Unix security works well for seperating users from each other, and for letting them safely use resources provided by an administrator. However, it makes it darned hard for users to collaborate with each other. Imagine you want to use A's compiler to compile B's program and save it in a file owned by C. A, B, and C have agreed to this. The compiler should only be able to access its own files, and the program, and the destination file.
This is a nightmare for Unix. I suppose you'd have to rewrite the compiler as a server and talk to it over sockets. But on EROS, if I understand right, a standard compiler would work just fine. Instead of giving an EROS compiler file names, you'd give it handles (capabilities) to the two files in question, and the compiler wouldn't be allowed to access any other files except for its own. Voila--users communicating, easily, without exposing themselves the way setuid or setgid would.
Communicating via the filesystem and via filenames is extremely ubiquitous in Unix. Once this goes to something better, IMHO it won't really look like Unix any more.
Both of these guys are still at it. They did *not* just spout some interesting ideas and then go back to hacking. They are busy putting in the 99% persperation that can transform "gee, what a clever idea" into "holy maceral, they just changed the world".
Specifically, Douglass Engelbert is working on making his idea of corporation/computer synergies come to life, and he's trying to explain to people just what the heck he's talking about (which to hear him, most people still don't get). Alan Kay is working on making his Dynabook goal finally happen, via the Squeak project (www.squeak.org). His original goals outstripped hardware of the 70's could do, but nowadays that is no longer an issue. In fact, when his group first announced the project a few years ago, they titled their paper "Back to the Future". Do they sound slightly condescending to the intervening decades of hacking? Well, they deserve to be!
Overall, let's not go by what the trade rags say is "hot". Trade rags are designed to give people warm fuzzies, not to excite them about difficult goals for computers in society.
Heck, all it took was the "I got started on an Apple II". I true suit wouldn't know what an Apple II is.
Still, he seems to give a practical reportcard for Linux as an office machine. The things he suggest would be approachable by a suit.
However, there is so much more available in other languages, for instance:
- numbers, characters, and strings are objects
- dynamic typing is an option
- decent type systems, especially wrt generics
- decent library of classes; largely this is due to typing problems
Maybe Java will at least get people thinking about the languages which set the context for so much of their work. If you aren't worried about applets, then, for many programming domains, languages like Lisp and Smalltalk give you the same benefits that Java does, plus more, and plus they have stable, mature implementations....so porting versus rewriting isn't that big of a deal.
Actually, you can just write a gcc machine specification on a supported machine, cross-compile gcc and whatever else you need for the new machine, and then figure out a way to initially load your new executables. No assembly required, except for the poor sap that makes the gcc spec work for the new machine.
Uhh, code bloat, yes. But instability?? No way. It's WAY easier to screw up using assembler than using C, and in turn it's way easier to screw up using C than using some higher-level language like Lisp or Smalltalk.
I've been typing on Dvorak for about a year, and the huge benefit is *comfort*, not speed.
Sure, dvorak certainly faster. But it's not faster by more than a factor of 1.5-2 times. And furthermore, most people are far below the speed limit that either layout imposes; they'd benefit more from taking some typing lessons than they would from learning a new layout.
But even so, switch to dvorak. You're hands will love you. And, it only takes about a month to do it. What's a month, compared to however much time you plan to spend using computers in your life?
And incidentally, it's *not* that hard to remain able to use both kinds of keyboard layout. I certainly can type okay on Qwerty, though it feels slow and awkward....
Umm, in dvorak, all the vowels are on the home row under the left hand, and all the most frequent consonants are on the home row under the right hand.
Don't you think that Dvorak causes hands to alternate more often?
In Windows98, just look in the Keyboard control panel. In Linux, do "loadkeys dvorak". On Macs, download a dvorak layout and add it to some folder somewhere.
Can we please stop this worshiping of GUIs as being the defining characteristic of modern software? I've even heard people complain that some technique or another is useless because it won't work on "real" code--ie, code that is all GUI and no substance.
But what about:
- network infrastructure
- missile guidance
- WWW search engines
- medical devices
just to quickly name a few? The important parts of these things don't have a GUI involved. Coding GUIs is just one general skill.
The really important things aren't changing that fast. In fact, from the little time I do spend with older guys, I'm reminded of just how much of whippersnappers *haven't* caught on to, that *they* knew decades ago.
Lex
Can we please stop this worshiping of GUIs as being the defining characteristic of modern software? I've even heard people complain that some technique or another is useless because it won't work on "real" code--ie, code that is all GUI and no substance.
But what about:
- satellite control
- Internet search engines
- medical devices
just to quickly name a few? The important parts of these things don't have a GUI involved. Coding GUIs is just one general skill--a relatively easy one when you think about stuff like the above.
Lex
Can we please stop this worshiping of GUIs as being the defining characteristic of modern software? I've even heard people complain that some technique or another is useless becuase it won't work on "real" code--ie, code that is all GUI and no substance.
But what about:
Can we please stop this worshiping of GUIs as being the defining characteristic of modern software? I keep hearing people talk about GUI skills as being skills of the new day, and I keep hearing people complain that some technique or other is useless becuase it doesn't work with GUI code.
The fact is, if the GUI is really a significant part of a program, then either:
1) The program isn't that intellectually challenging, as it's just a bunch of GUI code.