...we're still discussing things like screen corners and windows!
We look at the entire contents of our computers through tiny little screens. Imagine if you had to access your desk and filing cabinet in 2D through a 21" rectangle?
We manipulate the contents of our computers through keyboards and mice. When you put a piece of paper in a folder in the real world, do you do it by pointing and clicking? No, you pick up the piece of paper with one hand, grab the folder with the other and flip it open, slip the paper in, etc. Much quicker and more fluid.
Until we start exploiting the much more powerful methods of interaction that humans are capable of, HCI is not likely to make any great leaps forward.
Apple haven't disabled SUID binaries, just SUID scripts. SUID scripts are fundamentally insecure (do a google on "setuid script" for some references) and are already disabled in every other major unix distribution.
The TRS-80: a 64 character by 16 line screen meant a total of 1KB or video memory. Not only that, but on the model I and original model II the bytes in that memory were only 7-bit. (There were no lower case characters, and the graphics resolution of 128*48 was achieved by setting bit 6 and using bits 0-5 to represent the six pixels within the space a normal character took up.)
I remember being astounded by the 512x384 resolution of the first Mac. To think that you'd devote 24KB of memory just to the screen!
We'd like be able to easily write tools to parse and modify code so we can quickly do refactoring, etc. Makes sense.
So obviously major programming languages should publish their parsers as libraries to make things like this easy to write...
Oh, no, wait a sec, I have a much better idea: let's make programmers write code in a way that's trivial to parse. Yeah, then writing the tools will be easy! Brilliant! The fact that it makes writing any code a lot harder is something we can solve by writing fancier editors!
And while I'm at it, I'm sick of the way there are all these cars on the road while I'm trying to get somewhere. I think there should be a new rule that everyone has to give way to me. Hell, everybody else should be made to ride bicycles.
Putting my nerd hat on, the really cool thing about developing for the Newton was the programming language that it used, called (unimaginatively) NewtonScript. Don't let the "Script" fool you...it was a serious language: bytecode interpreted, garbage collected, fast, compact. Pretty impressive for something running on a handheld back in the early 90s! I spent a while tinkering around with writing a NewtonScript emulator, and the internals of the language were beautifully designed. (I still struggle with Java today because it just feels so incredibly clunky in comparison.)
One thing which would make emulating a Newton difficult is the memory management. It used an incredibly fine-grained MMU. I can't remember the page size, but basically it did mark-compact garbage collection, and did the compact bit by just shuffling page mappings in the MMU! Very neat, but difficult to fake efficiently on other hardware.
Slashdot Mirror
My Westpac (Bank of Melbourne) Visa debit card works just fine.
...we're still discussing things like screen corners and windows!
We look at the entire contents of our computers through tiny little screens. Imagine if you had to access your desk and filing cabinet in 2D through a 21" rectangle?
We manipulate the contents of our computers through keyboards and mice. When you put a piece of paper in a folder in the real world, do you do it by pointing and clicking? No, you pick up the piece of paper with one hand, grab the folder with the other and flip it open, slip the paper in, etc. Much quicker and more fluid.
Until we start exploiting the much more powerful methods of interaction that humans are capable of, HCI is not likely to make any great leaps forward.
Apple haven't disabled SUID binaries, just SUID scripts. SUID scripts are fundamentally insecure (do a google on "setuid script" for some references) and are already disabled in every other major unix distribution.
Well back when I was a young lad...
The TRS-80: a 64 character by 16 line screen meant a total of 1KB or video memory. Not only that, but on the model I and original model II the bytes in that memory were only 7-bit. (There were no lower case characters, and the graphics resolution of 128*48 was achieved by setting bit 6 and using bits 0-5 to represent the six pixels within the space a normal character took up.)
I remember being astounded by the 512x384 resolution of the first Mac. To think that you'd devote 24KB of memory just to the screen!
We'd like be able to easily write tools to parse and modify code so we can quickly do refactoring, etc. Makes sense.
So obviously major programming languages should publish their parsers as libraries to make things like this easy to write...
Oh, no, wait a sec, I have a much better idea: let's make programmers write code in a way that's trivial to parse. Yeah, then writing the tools will be easy! Brilliant! The fact that it makes writing any code a lot harder is something we can solve by writing fancier editors!
And while I'm at it, I'm sick of the way there are all these cars on the road while I'm trying to get somewhere. I think there should be a new rule that everyone has to give way to me. Hell, everybody else should be made to ride bicycles.
*Takes gun, shoots self in head*
Putting my nerd hat on, the really cool thing about developing for the Newton was the programming language that it used, called (unimaginatively) NewtonScript. Don't let the "Script" fool you...it was a serious language: bytecode interpreted, garbage collected, fast, compact. Pretty impressive for something running on a handheld back in the early 90s! I spent a while tinkering around with writing a NewtonScript emulator, and the internals of the language were beautifully designed. (I still struggle with Java today because it just feels so incredibly clunky in comparison.)
One thing which would make emulating a Newton difficult is the memory management. It used an incredibly fine-grained MMU. I can't remember the page size, but basically it did mark-compact garbage collection, and did the compact bit by just shuffling page mappings in the MMU! Very neat, but difficult to fake efficiently on other hardware.