The SD component of Rendezvous doesn't use DNS servers per se. Any machine that has services (and that can be any node on the net) advertises these services using multicast DNS.
mDNS is used both to advertise available machines, and the services on those machines. So, essentially, the service-discovery component of Rendezvous is a decentralized, local-link DNS service -- it even uses the DNS protocol (albeit multicasted).
And for the people who keep bitching about UDP broadcasts: first of all, multicast != broadcast. But more to the point, I haven't found Rendezvous to be particularly chatty; Apple claims in its docs to have gone to lengths to prevent it from spamming the network. (The developer docs include some thinly veiled references to NetBIOS.)
On the contrary: if they do this right, it could really help hardware compatibility.
In the case of Sun and Apple machines, once you've got the Open Firmware driver in flash or ROM on the card, it just works. You can use it from the firmware, boot the system from it (if applicable), etc.
Contrast with my damn PC, which can't even boot firewire or my USB key, despite having both ports on the motherboard, where the BIOS people should have been able to make them fully compatible.
EFI has the potential to be a more modular solution (hence the E in EFI) where third-parties -- Promise, Adaptec, 3COM if they're still around -- can drop in drivers. No more relying on your mobo/BIOS manufacturer for boot-and-root support for your Megatron IV whatever, or remote console support for your Groovynet card.
The extra CPU performance is now suddenly needed because IBM keeps encouraging ISV'S to write for Websphere, in Java, so you now need 10 times more memory and CPU performance than you previously did to perform the same task.
Your post is, for the most part, dead-on and well-put, but I can tell you're not an enterprise Java developer.
Our transaction processing systems were recently moved to Java from C (Solaris on a Sunfire 6800, 8-way SPARC).
Yes, they require more memory. This doesn't really concern us because we spend far less time tracking down dangling pointers and memory leaks now. The increase in memory seems to be about 4x-6x for our system, which still brings it in under a gig.
No, they do not require more CPU. Several parts of our application actually run faster than the C version. I credit the Hotspot on-the-fly optimization crap for this to some degree, but I'm honestly not sure what the deal is. (And I'm our profiling guy. Ain't that sad?:-)
But more importantly, as you mentioned, on big iron the I/O throughput tends to be the bottleneck anyway. Our transaction-processing systems tend to sit happily with significant idle percentages while positively slamming the disks and databases.
We're running inside Sun's Solaris JVM in a hacked-up proprietary version of EJB, using Tomcat for the frontend. I can't imagine that Websphere has much higher overhead, though I could certainly be wrong.
That's not entirely true. The KB article linked from the SecUpd description provides a screenshot of the approval dialog.
Basically, it notes that the app is being started for the first time, and it says that unless you expected to see that app come up in response to whatever you just did, kill it by pressing 'Cancel.'
I think this is a pretty good way of handling the situation. They could have left the hole unplugged, or simply disabled the functionality in general. The dialog box strikes me as a good compromise.
However, I do think a little more info might be nice, like how long ago the app was installed, etc. Might make it harder for a new app to masquerade under the name of an old app.
Disclaimer: I didn't use OSX before Panther, so this may not apply to the version you have.
Simple Finder is an incredible pain in the ass and confuses the hell out of Windows users. My girlfriend is largely computer-illiterate (she's memorized the motions and screen locations needed to operate Office, but not much else). I set up a limited account on my iBook because she couldn't seen to get to the web browser without dragging my Terminal icon off the dock. But that's a diatribe for another time.
I set up Simple Finder. No good. I can't blame her -- I couldn't really figure out how to get much actual work done with it.
In the end, I've been using a straight Limited Account for my Guest acct on the laptop, with much success. MacOS X already does a good job of keeping users out of one anothers' stuff, by properly setting homedir modes and whatnot. I've been working for a couple of weeks to bypass the Limited Account limitations, without luck. If you declare that the user cannot run a particular application, I haven't figured out a way around it that doesn't require admin.
However, unlike my experience with Windows, a limited account on OS X is still quite usable. Programs don't automatically expect to have root, and aren't able to sneak off and get it without asking (*cough*WinIE*cough*). If the need arises, the Auth Services password-dialog provides a way for an employee to work magic if necessary.
My recommendations, therefore: 1. Set up a 'Managed' account for the coffee people. Don't do per-user accounts unless you want to set up an LDAP server to handle it; cloning account settings on a single-user MacOS X system is a bitch. Retain an admin account for the employees. 2. Whitelist, not blacklist, the apps the user can run. Give them access to Safari and whatever else. Don't let them dork with the dock, etc. Specifically allowing access to a handful of apps will prevent them from firing up a new one from a USB key. Because they'll try. Oh, they'll try. 3. Unfortunately, I'd recommend against giving them iChat. iChat, unlike Windows AIM and GAIM, doesn't give you an easy way to switch accounts -- which is a must-have on a public terminal. 4. Lock down the keychain. Set Safari to not save passwords. Locking the keychain (with some known but non-obvious password) will prevent users from saving new items into it. This is a good thing. 5. Giving access to iTunes puts you in an interesting legal gray area. Like iChat, it provides no easy way to change accounts (in terms of iTMS). It also enables users to rip CDs. This may not be a good idea. 6. Unfortunately, OS X does not provide disk quotas, as far as I can tell (please, if someone knows different, clue me in!). The support is there in the filesystem, but there doesn't appear to be a UI. Keep this in mind. 7. As admin, periodically use Repair Permissions in Disk Utility to check for anything that's become accessible to the peons. More importantly, do this after you're done with the initial software install -- you'd be amazed at how much commercial software starts out world-writeable. (Bad Adobe.)
In the case of Gentoo, I treat the file hierarchy as follows: / and/usr: managed by Portage./usr/local: software I can't get through Portage, that I install manually.
Gentoo's file hierarchy is annoyingly loose, in my opinion, but this is common to most Linux distros. (I'm still a big fan of FreeBSD's "/ to boot,/usr for the system,/usr/local for all third-party software" approach.)
However, complaining that you haven't set PATH properly in your.profile is a poor reason to rag on a directory layout. I use ~/.bin for scripts and binary overrides, but since I doubt that's in your PATH, do you hate this too?:-)
This isn't a region or language lock-out. It's a language-aware installer that lacks a localization for your region.
The problem here, really, is that the installer won't offer to install some default localization when it can't find an appropriate one. There isn't some massive evil company trying to keep you from using their software.
Why not kick the computer to English for the duration of the install, and then switch it back?
I know you're asking for an SLR, but you might wish to look at the Minolta DiMAGE Z1/Z2.
It's SLR-form-factor and has easily accessible manual controls (though manual focus is with the cursors, rather than a focus ring like the Sonys). The built-in lens is, iirc, 350mm-equivalent, but fast enough at wide-angle settings that I've gotten some good low-light work out of it.
Personally, I'm rather frightened of digicams with removable lenses. Unlike a 35, where dust that enters winds up on the removable film, I don't see where the dust would go. My digi-SLR-wielding friends refer to them as "selectable lenses," in the sense that you pick it on purchase.
But I'd strongly recommend at least playing with a Z1 or Z2 before you make your purchase. Some of the features, like the 60fps LCD, are awfully hard to appreciate until you actually see them -- and then it clicks. I have a Z1; the Z2 is apparently lower-noise and with some firmware upgrades like real-time contrast histogram.
(The lower-noise part blows me away. A lot of the shots on my website, starting with the upright bass and below, were 30s-1m exposures in near darkness. Not too bad, for a CCD.)
I own one of the Pioneer decks they reference in the article. Its display is positively stunning, though I wish I'd waited a couple years for the color ones that can play MPEG off of the CD. Mmm.
In the article, though, they list among OLED's advantages "1000 hour life."
That's 41 and two-thirds days. This is clearly wrong; my stereo's been going strong for nearly two years.
Perhaps I'm simply naive about PPC32/64 porting issues (okay, no, I'm not), but y'all are aware that the recent JDKs have full source available?
I mean, yes, it will take a bit of nudging to get it to compile if you're on an unexpected platform. (Most of my work's been on FreeBSD.) But it's not like you have to wait for the graces of Sun or IBM to deem you worthy to have a binary JDK.
That's why I was always confused about people saying "FreeBSD is great, but no Java!" right after I'd done a `make install` in the jdk14 directory. Is there any reason why this wouldn't be the same deal?
Re:Thinking of Switching to a OSX for a laptop
on
Fix a Troubled Mac
·
· Score: 2, Informative
They do 'just work,' as long as you don't surprise them.
I bought an iBook, my first Mac, in October. It's been basically trouble-free. I've had it crash once, by running strings(1) on an audio CD. This was apparently not something Apple had anticipated, but I've submitted the bug, so we'll see.
The only hardware-compatibility issues I've had have been my eight-year-old Intel webcam (unsupported) and my father's bleeding-edge Sony external DVD-R (unsupported as a burner). Everything else has worked great.
Frankly, I wouldn't go back to Linux on a laptop until suspend works properly. Having the system up in a second or so after opening the lid is quite pleasant.
This is similar to what FFS and UFS do. Not by fragmenting files per se, but by distributing file data across heads and platters in the drive to parallelize access without actually having to move anything.
I'm sure HPFS used some of those techniques, as FFS was published public-domain in about '86, iirc.
Now-adays, most cheap desktop drives are single-sided single-platter jobs, so I'm not sure if this optimization is really useful for most of us.
Or, a more mainstream example: one of the main problems with W^X or NX arrangements of late has been Java JIT compilers.
After all, the entire point of a (fast) Java implementation is that it's periodically rewriting its code based on profiling data. That's awfully hard for the hardware to distinguish from a good ol' buffer overflow.
IIRC, it was MS-DOS 6 that included MSAV, their antivirus program -- as well as a couple other technologies that they stol^H^H^H^Hinnovated, such as the first go-round of their disk compression software (DiskSpace? DriveSpace? I can never remember which is which). It wasn't until about 6.22 that the offending technologies were stripped out.
However, with their recent invulnerability to litigation (by the Justice Department, even!), I 'spect they're prolly ballsy enough to try again.
Re:New product: the iWhoopie Cushion
on
Directed Sound
·
· Score: 1
three old ladies in the back row going at it like the trolls in The Hobbit.
Man, I don't know what kind of messed up version of The Hobbit you read, but I don't rememb......er. Right.
One of the things Newton prided himself on was his virginity. Despite being married, he claimed to be a virgin up until his death.
I can see a few options for this. 1. Being the ubergeek of his time, he simply couldn't get laid. 2. He was lying. 3. He was confused as to what 'virgin' meant. 4. He was gay.
Now, I should mention that, for #4 to hold true, he'd either have had to not act on his impulses, or to have defined sex as being between a man and a woman. I think the latter's probably quite likely.
So depicting Newton as gay, while potentially controversial, isn't entirely improbable.
You're thinking of a solar sail. Ion drives derive thrust directly from the force of the escaping gas (lightweight but high energy), generally xenon.
Trying to ride the 'wind' from your own ion drive is very similar to trying to windsurf by blowing into your own sail -- or, to use a more familiar analogy, pulling one's self up by one's own bootstraps.
I think everyone's overlooking the very real possibility that these chickens were used for more than just heat.
Like styrofoam in the H-bomb, this seemingly innocuous packing material (chickens) might be converted to plasma by radiation pressure, thereby dramatically increasing the explosive yield of the device.
Just wait. I give it 20 years, and we'll see these docs declassified. Of course, then we'll have to worry about rogue states building C-bombs.
Honestly, I don't see the problem. Virtually all languages have some sort of global namespace -- the class and package hierarchy in Java, imported functions or global variables in C, etc. Most programmers seem to adopt nomenclature to identify the scope of a variable. I see a lot of _underbar for member variables, ALL_CAPS for constants, UpperCaseNames for classes in Java and C++, etc.
What this does is (1) enforce such a standard, and (2) make it instantly apparent what the scope of an identifier is.
Contrast with Java (which is industrial strength -- I'm currently on break from writing transaction processing systems in it). Class names are global in Java within the scope of your package imports. Sun recommends you CapitalizeYourClasses and doNotCapitalizeLocalsOrMethods. However, that doesn't keep the occasional VB/C# programmer from falling into your lap and doing everything wrong, which can make the code awfully hard to read.
I'm not generally a fan of bondage-domination languages, but this is a case where I make an exception. (I'm also a fan of the scoping characters used in Ruby, for example.)
Naw -- Smalltalk's class-based, like Simula. You're probably thinking of Self and/or NewtonScript.
Prototype-based inheritance, while not personally within my tastes, is nothing to scoff at. In Self, the inheritance scheme worked its way through the entire language, from variable scoping to collections, and allowed a lot of optimizations. Self still holds the claim, as far as I know, of being the fastest pure-OO language, with a relatively small interpreter/JIT to boot.
(Oops, that might qualify as a 'boot' pun.)
One difference, of course, is that while Self was designed specifically to be JIT compiled (though they didn't call it that back then), Prothon doesn't seem to be. But I might be wrong.
Without the compilation-on-the-fly, Self would likely perform far worse....
Slashdot Mirror
Close, but with one exception:
The SD component of Rendezvous doesn't use DNS servers per se. Any machine that has services (and that can be any node on the net) advertises these services using multicast DNS.
mDNS is used both to advertise available machines, and the services on those machines. So, essentially, the service-discovery component of Rendezvous is a decentralized, local-link DNS service -- it even uses the DNS protocol (albeit multicasted).
And for the people who keep bitching about UDP broadcasts: first of all, multicast != broadcast. But more to the point, I haven't found Rendezvous to be particularly chatty; Apple claims in its docs to have gone to lengths to prevent it from spamming the network. (The developer docs include some thinly veiled references to NetBIOS.)
Sure, you can purchase them -- but shipping's a bitch.
On the contrary: if they do this right, it could really help hardware compatibility.
In the case of Sun and Apple machines, once you've got the Open Firmware driver in flash or ROM on the card, it just works. You can use it from the firmware, boot the system from it (if applicable), etc.
Contrast with my damn PC, which can't even boot firewire or my USB key, despite having both ports on the motherboard, where the BIOS people should have been able to make them fully compatible.
EFI has the potential to be a more modular solution (hence the E in EFI) where third-parties -- Promise, Adaptec, 3COM if they're still around -- can drop in drivers. No more relying on your mobo/BIOS manufacturer for boot-and-root support for your Megatron IV whatever, or remote console support for your Groovynet card.
This is a Good Thing.
Your post is, for the most part, dead-on and well-put, but I can tell you're not an enterprise Java developer.
Our transaction processing systems were recently moved to Java from C (Solaris on a Sunfire 6800, 8-way SPARC).
Yes, they require more memory. This doesn't really concern us because we spend far less time tracking down dangling pointers and memory leaks now. The increase in memory seems to be about 4x-6x for our system, which still brings it in under a gig.
No, they do not require more CPU. Several parts of our application actually run faster than the C version. I credit the Hotspot on-the-fly optimization crap for this to some degree, but I'm honestly not sure what the deal is. (And I'm our profiling guy. Ain't that sad?
But more importantly, as you mentioned, on big iron the I/O throughput tends to be the bottleneck anyway. Our transaction-processing systems tend to sit happily with significant idle percentages while positively slamming the disks and databases.
We're running inside Sun's Solaris JVM in a hacked-up proprietary version of EJB, using Tomcat for the frontend. I can't imagine that Websphere has much higher overhead, though I could certainly be wrong.
That's not entirely true. The KB article linked from the SecUpd description provides a screenshot of the approval dialog.
Basically, it notes that the app is being started for the first time, and it says that unless you expected to see that app come up in response to whatever you just did, kill it by pressing 'Cancel.'
I think this is a pretty good way of handling the situation. They could have left the hole unplugged, or simply disabled the functionality in general. The dialog box strikes me as a good compromise.
However, I do think a little more info might be nice, like how long ago the app was installed, etc. Might make it harder for a new app to masquerade under the name of an old app.
Sounds like a neat program. Have a question, though:
How does this interact with 10.3's hot file clustering and on-the-fly defrag? It sounds like the results would be pessimal.
Disclaimer: I didn't use OSX before Panther, so this may not apply to the version you have.
Simple Finder is an incredible pain in the ass and confuses the hell out of Windows users. My girlfriend is largely computer-illiterate (she's memorized the motions and screen locations needed to operate Office, but not much else). I set up a limited account on my iBook because she couldn't seen to get to the web browser without dragging my Terminal icon off the dock. But that's a diatribe for another time.
I set up Simple Finder. No good. I can't blame her -- I couldn't really figure out how to get much actual work done with it.
In the end, I've been using a straight Limited Account for my Guest acct on the laptop, with much success. MacOS X already does a good job of keeping users out of one anothers' stuff, by properly setting homedir modes and whatnot. I've been working for a couple of weeks to bypass the Limited Account limitations, without luck. If you declare that the user cannot run a particular application, I haven't figured out a way around it that doesn't require admin.
However, unlike my experience with Windows, a limited account on OS X is still quite usable. Programs don't automatically expect to have root, and aren't able to sneak off and get it without asking (*cough*WinIE*cough*). If the need arises, the Auth Services password-dialog provides a way for an employee to work magic if necessary.
My recommendations, therefore:
1. Set up a 'Managed' account for the coffee people. Don't do per-user accounts unless you want to set up an LDAP server to handle it; cloning account settings on a single-user MacOS X system is a bitch. Retain an admin account for the employees.
2. Whitelist, not blacklist, the apps the user can run. Give them access to Safari and whatever else. Don't let them dork with the dock, etc. Specifically allowing access to a handful of apps will prevent them from firing up a new one from a USB key. Because they'll try. Oh, they'll try.
3. Unfortunately, I'd recommend against giving them iChat. iChat, unlike Windows AIM and GAIM, doesn't give you an easy way to switch accounts -- which is a must-have on a public terminal.
4. Lock down the keychain. Set Safari to not save passwords. Locking the keychain (with some known but non-obvious password) will prevent users from saving new items into it. This is a good thing.
5. Giving access to iTunes puts you in an interesting legal gray area. Like iChat, it provides no easy way to change accounts (in terms of iTMS). It also enables users to rip CDs. This may not be a good idea.
6. Unfortunately, OS X does not provide disk quotas, as far as I can tell (please, if someone knows different, clue me in!). The support is there in the filesystem, but there doesn't appear to be a UI. Keep this in mind.
7. As admin, periodically use Repair Permissions in Disk Utility to check for anything that's become accessible to the peons. More importantly, do this after you're done with the initial software install -- you'd be amazed at how much commercial software starts out world-writeable. (Bad Adobe.)
Good luck!
In the case of Gentoo, I treat the file hierarchy as follows: /usr: managed by Portage. /usr/local: software I can't get through Portage, that I install manually.
/usr for the system, /usr/local for all third-party software" approach.)
.profile is a poor reason to rag on a directory layout. I use ~/.bin for scripts and binary overrides, but since I doubt that's in your PATH, do you hate this too? :-)
/ and
Gentoo's file hierarchy is annoyingly loose, in my opinion, but this is common to most Linux distros. (I'm still a big fan of FreeBSD's "/ to boot,
However, complaining that you haven't set PATH properly in your
This isn't a region or language lock-out. It's a language-aware installer that lacks a localization for your region.
The problem here, really, is that the installer won't offer to install some default localization when it can't find an appropriate one. There isn't some massive evil company trying to keep you from using their software.
Why not kick the computer to English for the duration of the install, and then switch it back?
I know you're asking for an SLR, but you might wish to look at the Minolta DiMAGE Z1/Z2.
It's SLR-form-factor and has easily accessible manual controls (though manual focus is with the cursors, rather than a focus ring like the Sonys). The built-in lens is, iirc, 350mm-equivalent, but fast enough at wide-angle settings that I've gotten some good low-light work out of it.
Personally, I'm rather frightened of digicams with removable lenses. Unlike a 35, where dust that enters winds up on the removable film, I don't see where the dust would go. My digi-SLR-wielding friends refer to them as "selectable lenses," in the sense that you pick it on purchase.
But I'd strongly recommend at least playing with a Z1 or Z2 before you make your purchase. Some of the features, like the 60fps LCD, are awfully hard to appreciate until you actually see them -- and then it clicks. I have a Z1; the Z2 is apparently lower-noise and with some firmware upgrades like real-time contrast histogram.
(The lower-noise part blows me away. A lot of the shots on my website, starting with the upright bass and below, were 30s-1m exposures in near darkness. Not too bad, for a CCD.)
I know it's still not what you're looking for, but nVidia's binary drivers are not exclusive to Linux. I use them with much success on FreeBSD.
They're even in ports.
Really, the problem is that they're IA64/IA32/AMD64 specific (they aren't just x86, they're available for those three archs).
I own one of the Pioneer decks they reference in the article. Its display is positively stunning, though I wish I'd waited a couple years for the color ones that can play MPEG off of the CD. Mmm.
In the article, though, they list among OLED's advantages "1000 hour life."
That's 41 and two-thirds days. This is clearly wrong; my stereo's been going strong for nearly two years.
Just FYI.
Perhaps I'm simply naive about PPC32/64 porting issues (okay, no, I'm not), but y'all are aware that the recent JDKs have full source available?
I mean, yes, it will take a bit of nudging to get it to compile if you're on an unexpected platform. (Most of my work's been on FreeBSD.) But it's not like you have to wait for the graces of Sun or IBM to deem you worthy to have a binary JDK.
That's why I was always confused about people saying "FreeBSD is great, but no Java!" right after I'd done a `make install` in the jdk14 directory. Is there any reason why this wouldn't be the same deal?
They do 'just work,' as long as you don't surprise them.
I bought an iBook, my first Mac, in October. It's been basically trouble-free. I've had it crash once, by running strings(1) on an audio CD. This was apparently not something Apple had anticipated, but I've submitted the bug, so we'll see.
The only hardware-compatibility issues I've had have been my eight-year-old Intel webcam (unsupported) and my father's bleeding-edge Sony external DVD-R (unsupported as a burner). Everything else has worked great.
Frankly, I wouldn't go back to Linux on a laptop until suspend works properly. Having the system up in a second or so after opening the lid is quite pleasant.
This is similar to what FFS and UFS do. Not by fragmenting files per se, but by distributing file data across heads and platters in the drive to parallelize access without actually having to move anything.
I'm sure HPFS used some of those techniques, as FFS was published public-domain in about '86, iirc.
Now-adays, most cheap desktop drives are single-sided single-platter jobs, so I'm not sure if this optimization is really useful for most of us.
Or, a more mainstream example: one of the main problems with W^X or NX arrangements of late has been Java JIT compilers.
After all, the entire point of a (fast) Java implementation is that it's periodically rewriting its code based on profiling data. That's awfully hard for the hardware to distinguish from a good ol' buffer overflow.
They did.
They got sued.
They don't anymore.
IIRC, it was MS-DOS 6 that included MSAV, their antivirus program -- as well as a couple other technologies that they stol^H^H^H^Hinnovated, such as the first go-round of their disk compression software (DiskSpace? DriveSpace? I can never remember which is which). It wasn't until about 6.22 that the offending technologies were stripped out.
However, with their recent invulnerability to litigation (by the Justice Department, even!), I 'spect they're prolly ballsy enough to try again.
three old ladies in the back row going at it like the trolls in The Hobbit.
...er. Right.
Man, I don't know what kind of messed up version of The Hobbit you read, but I don't rememb...
Don't be silly! If you wanted FLAC and Vorbis playback, 16 hours of battery life, and gapless or crossfaded playback, you'd just buy a Rio Karma.
(Seriously.)
Ahrm.
So why is it you need PCMCIA? Is the current Cardbus slot not sufficient? It's like PCMCIA, only much faster and with a wider bus.
Oh, and it's backwards compatible.
Let me guess -- didn't read the specs? I understand.
One of the things Newton prided himself on was his virginity. Despite being married, he claimed to be a virgin up until his death.
I can see a few options for this.
1. Being the ubergeek of his time, he simply couldn't get laid.
2. He was lying.
3. He was confused as to what 'virgin' meant.
4. He was gay.
Now, I should mention that, for #4 to hold true, he'd either have had to not act on his impulses, or to have defined sex as being between a man and a woman. I think the latter's probably quite likely.
So depicting Newton as gay, while potentially controversial, isn't entirely improbable.
You're thinking of a solar sail. Ion drives derive thrust directly from the force of the escaping gas (lightweight but high energy), generally xenon.
Trying to ride the 'wind' from your own ion drive is very similar to trying to windsurf by blowing into your own sail -- or, to use a more familiar analogy, pulling one's self up by one's own bootstraps.
I think everyone's overlooking the very real possibility that these chickens were used for more than just heat.
Like styrofoam in the H-bomb, this seemingly innocuous packing material (chickens) might be converted to plasma by radiation pressure, thereby dramatically increasing the explosive yield of the device.
Just wait. I give it 20 years, and we'll see these docs declassified. Of course, then we'll have to worry about rogue states building C-bombs.
This is something they inherited from Smalltalk.
Honestly, I don't see the problem. Virtually all languages have some sort of global namespace -- the class and package hierarchy in Java, imported functions or global variables in C, etc. Most programmers seem to adopt nomenclature to identify the scope of a variable. I see a lot of _underbar for member variables, ALL_CAPS for constants, UpperCaseNames for classes in Java and C++, etc.
What this does is (1) enforce such a standard, and (2) make it instantly apparent what the scope of an identifier is.
Contrast with Java (which is industrial strength -- I'm currently on break from writing transaction processing systems in it). Class names are global in Java within the scope of your package imports. Sun recommends you CapitalizeYourClasses and doNotCapitalizeLocalsOrMethods. However, that doesn't keep the occasional VB/C# programmer from falling into your lap and doing everything wrong, which can make the code awfully hard to read.
I'm not generally a fan of bondage-domination languages, but this is a case where I make an exception. (I'm also a fan of the scoping characters used in Ruby, for example.)
Naw -- Smalltalk's class-based, like Simula. You're probably thinking of Self and/or NewtonScript.
Prototype-based inheritance, while not personally within my tastes, is nothing to scoff at. In Self, the inheritance scheme worked its way through the entire language, from variable scoping to collections, and allowed a lot of optimizations. Self still holds the claim, as far as I know, of being the fastest pure-OO language, with a relatively small interpreter/JIT to boot.
(Oops, that might qualify as a 'boot' pun.)
One difference, of course, is that while Self was designed specifically to be JIT compiled (though they didn't call it that back then), Prothon doesn't seem to be. But I might be wrong.
Without the compilation-on-the-fly, Self would likely perform far worse....