I have a 180gb external Firewire 400 drive that's been rebooted with Panther multiple times with no issues. Its clearly not any single factor that is causing the problems: that's what Macintouch is saying anyway.
Its not as clear cut as it being an ATA VI problem, anyway.
> If they can cause headache and nausea, >I think you can reasonably expect it to have other >effects such as malignant tumours
Wow. Turning myself upside down for 2 minutes can give me headaches and nausea. So can drinking beer!
I must "reasonably expect" those to give me brain tumours too!
Seriously though, there may or may not be a more serious problem than headaches, but there's precisely no evidence of that being presented, is there? (by the sounds of it, there's so few details no one can definatively say anything)
Others have been implying you're stupid not to have called the number on your card rather than the number on your answering machine, but I agree with you.
One does need to be careful: the natural thing to do is to call the number in the message, because who wants to call the generic number on the card and get lost in call tree hell when they have what should be the direct line to the right department?
And, as you said, when you did call the credit card company, they had no idea whether the number you had from the message was one of theirs or not: after all why would the monkey on the end of the phone necessarily know all of the fraud department's numbers?
So yeah: I think it is wise to be wary about these things.
... and I'll show you a perfectly correct implementation.
The JVM has a reasonable specification. The 1000s of classes that ship with it do not have a good specification. The closest you'll get is deciding whether it should work like version X.X_0X of Sun's JDK on Solaris. Or should you do what the Windows implementation does? or perhaps the Linux version? or maybe you want to do something different again to be in line with Apple's UI specs for OS X?
Correctness in these large systems is a myth, so I don't see a major problem with something being "more correct".
Well, is it *all* of them or *most* of them? If its *most* of them then there must be some that are worthy of the term "virtual world" and thus something to write about. If its none of them, then why not say so...
In any case a virtual world (The Matrix if you will) is hardly going to spring into being fully formed. There have to be steps to get there. Hopefully this book is about what steps have been tried.
What MMOGs have you tried, and what would you do differently?
I don't mean that seriously, but just before I graduated I was sitting talking with one of the professors who had taught my first year programming courses.
Over the course of the discussion we covered why they had used Miranda (functional, like Haskell) and Modula 2 in the starter courses (and indeed they'd switched from Modula to Turing the year after me).
The reasons she gave were almost word for word what you just said about 'public static void main()' and 'System.out.println'
Too much cruft too early, no matter how powerful it may be later, is bad.
My limited understanding is the Darwin kernel isn't a very pure example of Mach/microkernel design in any case.
IIRC the basic idea of a microkernel is that its very small, with the functionality of a traditional kernel being implemented by a number of processes (confusingly called servers, I think?) running on top of it, with user processing running onto of those servers. All communication between these kernel servers is implemented by message passing. "Mach messages" in this case. The idea being that each server is a seperate address space, so like user processes crashes in one don't take out another, and you can swap servers in and out in a dynamic fashion (think modules, or drivers). Of course, you pay for these benefits in terms of the messaging overhead.
As I understand it Darwin is implemented as a single server process ontop of the microkernel. So effectively its a monolithic kernel server ontop of a microkernel. So that would seem to remove most of the overhead (and many of the benefits). This is all from memory though, so I may be 100% wrong.
I'd be interested in learning more about why they chose this design route. Anyone got any links? (maybe I'll look in Google later).
My troll loving friend... Oh boy, do I even have to respond to your post. You have no idea what are talking about if you haven't used NT in 10 years and have no idea about Windows 2000 let alone WindowsXP. Geesh.
English comprehension clearly isn't your strongest point. The two statements I made were:
but then I've used Windows NT and its "File Manager" for over half a decade now,
Unfortunately I've not seen much beyond Windows 2000 regularly. XP is still a bit of a mystery to me.
I'll give you the benefit of the doubt in that the second sentence is not as clear as it could be, but what I'm clealry saying here is that I have used NT for more than half a decade, and I have used Windows 2000 extensively, but I have not yet used Windows XP for any length of time
Infact I've been using Windows NT 4 and 2000 almost daily since some point in '97, and since NT 4 came out in '96, that's not bad. Windows NT 3.5 and XP I know less about. Where you got the idea I've not touched NT in 10 years from, I have no idea.
Os for the Mac file manager's need to be more threaded, for proof of my claim I suggest you check the last updates to OSX and the touted additions of better threading in the file manager. (You can find this in Apple's own press releases, as well as users complaining in the newsgroups all over the net. Find them yourself if you can figure out the little search button on your browser.)
You obviously missed the part where I said " I mean, I wouldn't claim it [the Mac Finder] is perfect even in 10.2,". I don't disagree with you there, and even if I did, I don't see the point in insulting me with respect to my ability to use Google. You're very immature.
OSX and the technologies that it brings to the Mac World are bringing new concepts to Apple and the developers that they haven't normally dealt with on a Mac in the past. This brings them power, but power they don't know how to turn back into the user interface experience, yet.
For example even the idea of not having the system bog down while playing an MP3, and doing several other tasks at the same time is something that is normal for a Windows user but exciting and new for Mac users. Even on the fastest Mac OS System9 loved to skip the sound and make the system almost unresponsive no matter how fast the processor was doing these same tasks. (Hence why Apple wanted and needed a preemptive OS for so long.)
Now, here I agree you have a point. I think you're right: some developers are finding dealing with pre-emptive multi-tasking challenges from a UI perspective. Perhaps I don't think the issues are as large as you do, but I agree they do come up.
See how pleasant that was? I might have rated you Interesting if that's what you'd said in the first place. What I objected to was the way you tried to bluster your way to a point by setting up straw men that you can burn down easily:
Complaining about OS X 10.0's file manager threading, rather than talking about specific problems remaining in 10.2.
Jumping into a rant about the Quicktime installer on Windows, which was probably written by a completely different group inside Apple, very likely years before OS X ever existed (it be relevant as an indication that Apple has a problem with pre-emptive UI, but its a very weak point. Its much more likely some developer made a personal taste decision and disabled the Minimize button on a whim)
Finally, grandstanding about how kernel level design issues must be the cause for all of these (poorly defined) problems, and challenging people to dare to reply to you:
And we would just waste ten messages debating why I disagree with Apple's OSX mach kernel decision. Which is why OSX on a whole is subject to less responsiveness than Linux or WindowsXP(NT).)
I wonder if you're a troll or just someone who likes to sounds clever?
It also just kills me that Apple installation software will fill the screen, like the user wants to set and watch it install. In the Windows world, this is unheard of. Even if the installation screen is maximized, we can just hit minimize and go on with our work while it installs.
Most Windows installers maximize their window, whereas all common Mac installers just use a regular window.
How many Windows users do actually minimize the installer screen though? How many just sit watching its pretty blue bar?
Every time I have to install QuickTime for a user, it makes me shake my head, since the QuickTime screen not only fills the screen with no option to minimize, but it even does this during the entire download process. Sure I can flick the Windows Key and go back to work, but what were they thinking? Every time I install QuickTime I think, Apple, you just are not getting the whole multi-application pre-emptive thing and what it means for your users.
Oh! Now in this paragraph we can all see you're not talking about installers on the Mac after all, you're talking about you're talking about the Quicktime for Windows installer. The fact you cannot minimize it sounds annoying, true. However, as you point out you can always press Windows-M to get rid of it. Or Alt-Tab one assumes...?
So infact the set of users who are effected by this issue comes down to those people who
actually want to minimize an installer rather than just watching it
don't know how to Windows-M or Alt-Tab
In other words, its a tiny annoyance in Apple's Windows installer which, while it should be corrected, has almost no effect on anyone...
Unfortunately this thinking will take some catching up, Microsoft has had a pre-emptive OS since 1993, threading and other issues for simultaneous application usage for users is far more mature in all of the NT products especially XP.
Have you actually any examples, beyond vague suggestions that the Mac "File Manager" wasn't multi-threaded enough in Mac OS X 10.0 ? I mean, I wouldn't claim its perfect even in 10.2, but then I've used Windows NT and its "File Manager" for over half a decade now, and you know, it has a few threading issues too. I don't want to be rude, but other than your poorly constructed installer rant, you don't actually seem to have any examples.
And we would just waste ten messages debating why I disagree with Apple's OSX mach kernel decision. Which is why OSX on a whole is subject to less responsiveness than Linux or WindowsXP(NT).)
Of course, you have links you could share with us to actual profiling results showing comparisons between MacOS, Windows and Linux (et al.). These show conclusively where "responsiveness differences" occur, and then proceed to demonstrate how these are surely caused by the Mach micro kernel and not any other factor like, just for example: hardware or boneheaded programing in the File Manager or GUI?
Please do post such material. It would be very interesting.
Well, interestingly enough, the config files are often bi-level... so you have:
[Code] - using logical names [J2EE Config file] - maps logical name to "physical name" [Vendor Config file] = maps "physical name" to parameters like hostname/port
So often even your J2EE config file can be used unaltered. What tends to happen is the J2EE config files started out with relatively few features, and the vendors added all of their stuff in the Vendor Condig File (value-added or proprietary features).
As J2EE is revised, the most commonly supported or desired features tend to move up into the J2EE Config File level. So when you upgrade to a new version you might find that things you previously had to configure on a vendor level may now be configured in an abstract portable way.
This is natural evolution. It has a cost though: the extra layer of indirection makes the initial setup more complex. Once you get it down though, its pretty easy to maintain, as a rule.
The J2EE standard doesn't cover everything you'd ever need to do to get an application off the ground.
eg, most enterprise applications allow you to connect to a database. J2EE defines a way of naming the database connection ("DataSource") with a logical name. Say "MyBigDB". This is a name bound into a JNDI tree - basically a directory. Give the directory "MyBigDB" and you get back an instance of DataSource that can connect to your database.
At some point these convenient names "MyBigDB" must be mapped to actual parameters (hostname, username, password, port number) of the database.
J2EE doesn't really specify this. Each vendor has their own config file syntax for doing this mapping.
So this is the sort of thing they mean when they say it takes "hours" to port. You find out where JBoss keeps its config files, what the syntax is, and how to map MyBigDB to the hostname etc.
Hopefully none of your code changes, its just a matter of defining mappings in config files. The more complex your application, the more points of contact with "the real world" or "the bare metal" it probably has. J2EE hides a lot, but it can't hide everything.
Hey! Earlier today this page:
XServe Design included a cool joke:
Designed for the computational clusters and distributed applications, this Xserve configuration delivers high-density processing power without the server features you won't need in a cluster enviroment. A single drive bay offers space for the operating system, and there's no optical drive, which means the front panel can offer more ventilation.
This does result in fewer blinkenlights. [Emphasis mine]
I looked again, and now its gone. Spoilsports!. Did anyone cache the original? Its quoted here:
At Macintouch. I swear I am not making this up!
Yes, my tone was somewhat harsh, but the exact thing I was responding to was:
"Native GUI support (Cocoa, Quartz) was non-existant. Java ran great - with CLI!"
Its very easy to read that and assume GUIs were not supported at all, or at best, were some sort of emulation. This just isn't true. They weren't based on Cocoa, true, but they were on Carbon and Quartz, which is just as "native". If it isn't, someone had better tell Apple (the Finder), Adobe (Photoshop) and Microsoft (Office) pretty quickly. All are Carbon applications.
Actually, all Swing GUIs are an emulation in some sense. Apple's is one of the most native implementations because its Aqua PLAF actually does call lots of native code (which the Sun Windows PLAF didn't last time I checked, so you could hack things and run the Window PLAF on X11 or Mac OS... but that could have changed). All that's really changed is the native layer used is now Cocoa rather than Carbon. Its not panacea. People are reporting all sorts of new GUI bugs - which is to be expected after such a huge change.
Apple's 1.3 VM was DEFINATELY NOT CLI ONLY.
It had a perfectly reasonable AWT/Swing implementation which was derived from the old Mac OS 9 implementation and ran ontop of Carbon, which means it did have the Aqua look and feel and it did run ontop of Quartz.
Now, we can talk about reimplementing AWT/Swing ontop of Cocoa rather than the crufty 20 year old foundation that is Carbon - and probably we can agree its a great thing, but it sure did take a long time. Its definately not the case that this is the first release with an Aqua GUI though!
How many people actually got the joke?
on
Hyatt Discusses Tabs
·
· Score: 2, Interesting
You've been rated funny, but I wonder how many people actually got the joke. Even someone from the South of England is unlikely to get the reference, never mind an American.
OK. I'll spill. In the North of England, a Tab is a cigarette, so they do indeed cause cancer.
Books obviously don't last forever. I have a lot of first editions lying around that are painfully out of date.
To see your sample code again, you put the book back on your shelf again. Evidently you need access to it for another month... so you pay another $1.33. If you never look at book again, you've saved $38.66 by finding its not really useful for $1.33. Sounds reasonable to me. The only real risk is opportunity cost - the slot's not there for some other new book you might want to read, but as you say yourself how many new technical books do you read in a month.
I'm not disagreeing with you completely - there's a whole lot of books I appreciate owning on paper. There are also some I wish I'd never bought, because I almost never look at them. This might be worthwhile as a screening process. I mean, if you find you really never take a book off your virtual bookshelf, you might as well buy a paper copy. If you read it through once and never look at it again, you've saved a lot of money.
Then again, there's always the chance of a second edition... and searchable technical books looks like a real plus to me (sometimes I can't even remember which book a code example is in, much less find it in the index!).
I can stand reading documentation onscreen. A good eBook reader would be better though.
You do have it straight, though actually, Mozilla itself will soon be dropping Classic (OS 9) support.
At that point they'll switch to a Unix back end with a Carbon front end. While a Cocoa port of the front end would be nice, its quite large, and the performance gains most likely lie in moving the back end to the Unix back end.
Chimera is not a Cocoa port of the entire Mozilla front end UI - its a completely seperate UI for "just the browser". Sort of like Phoenix, but more like Galeon or KMellon, because it doesn't use XUL.
Interestingly, one could presumably make a version of Chimera that used Apple's WebCore (the Safari rendering engine), and indeed Apple could always take the Safari UI and use Gecko (the Mozilla rendering engine) at some point in the future. I don't expect to see either happen though!
Picture the scene, its the mid-80s. Apple engineers want a way to network their dinky 9" screen toaster macs. All they have is a serial port, and almost no one has heard of Ethernet.
More importantly, the wife (landlord or whoever) is not going to stand for rewiring the house with some computer nonsense.
Solution: AppleTalk networking over LocalTalk cabling. ie, use the existing phone sockets and cabling to send data. By modern standards it crawls, but it works well and is still in use today (by some unfortunate souls).
Almost 20 years later you have HomePNA. There aren't many new ideas in this world.
Democracies, and speaking of debunking
on
David Brin On LOTR
·
· Score: 4, Insightful
>>Brin >>This yearning makes sense if you remember that >>arbitrary lords and chiefs did rule us for 99.44 >>percent of human existence. It's only been 200 >>years or so -- an eye blink -- that "scientific >>enlightenment" began waging its rebellion against >>the nearly universal pattern called feudalism
>pVoid >Not to break it to you Einstein, but democracy was >invented in ancient Greece. That's not a couple of >hundred years, it's a couple of thousand years... >just about as old as christianity itself.
Well, while we're busy being irratated....
Many people have already pointed out Greek democracy was hardly the same thing that we have now. I'll point out that you've seriously missed the point:
Brin is saying that for 200 years some reasonable proportion of the world has lived in a democracy. The fact a few Greeks had something like it before the birth of Christ is irrelevant - it was almost forgotten and certainly never much practised in the next 2000 years or so. He didn't say it hadn't been INVENTED, only that it wasn't USED.
>>Timidly at first, guilds and townsfolk rallied >>together and lent their support to kings, thereby >>easing oppression by local lords.
>Does he actually have proof of this, or is he >using the LoTR as a template?
I'll refer you to the history of mainland Europe, in particular you might like to read about what's now Belgium for a start.
>This guy hasn't read the Silmarillion probably.
I have. And the first 10 volumes of the History of Middle Earth, including the poetry (eek!) There's some merit in what you say, but its much more complex.
> It seems to me he's the typical Hollywoodist he >criticizes in his own essay: trying to attract >attention by shock value.
Actually, he's a widely respected sci fi author. He's been writing on these themes for several years. If he's using shock value its to needle you into thinking about the ideas he presents. You can disagree, of course, but that seems to be his motive to me.
(who couldn't bring himself to read beyond the first page---moderate accordingly)
I'll reply instead. Brin is a thinker. He doesn't necessarily give away his entire idea in the first paragraph.
Do yourself a favour and read the rest. Then you can decide if there's merit in the point he's actually making, rather than what you think he's saying.
Slashdot Mirror
Oh yea gods!
The horror. Don't remind me about that!
Actually, the Bobba Fett story line was the best bit.
You win the geekiest award.
I have a 180gb external Firewire 400 drive that's been rebooted with Panther multiple times with no issues. Its clearly not any single factor that is causing the problems: that's what Macintouch is saying anyway.
Its not as clear cut as it being an ATA VI problem, anyway.
> If they can cause headache and nausea,
>I think you can reasonably expect it to have other
>effects such as malignant tumours
Wow. Turning myself upside down for 2 minutes can give me headaches and nausea. So can drinking beer!
I must "reasonably expect" those to give me brain tumours too!
Seriously though, there may or may not be a more serious problem than headaches, but there's precisely no evidence of that being presented, is there? (by the sounds of it, there's so few details no one can definatively say anything)
Others have been implying you're stupid not to have called the number on your card rather than the number on your answering machine, but I agree with you.
One does need to be careful: the natural thing to do is to call the number in the message, because who wants to call the generic number on the card and get lost in call tree hell when they have what should be the direct line to the right department?
And, as you said, when you did call the credit card company, they had no idea whether the number you had from the message was one of theirs or not: after all why would the monkey on the end of the phone necessarily know all of the fraud department's numbers?
So yeah: I think it is wise to be wary about these things.
... and I'll show you a perfectly correct implementation.
The JVM has a reasonable specification. The 1000s of classes that ship with it do not have a good specification. The closest you'll get is deciding whether it should work like version X.X_0X of Sun's JDK on Solaris. Or should you do what the Windows implementation does? or perhaps the Linux version? or maybe you want to do something different again to be in line with Apple's UI specs for OS X?
Correctness in these large systems is a myth, so I don't see a major problem with something being "more correct".
Well, I think its sad anyone can get to +3 insightful without trying.
Can't say I'm surprised though.
Actually, yes I am, I'm surprised you didn't get to +5...
Well, is it *all* of them or *most* of them? If its *most* of them then there must be some that are worthy of the term "virtual world" and thus something to write about. If its none of them, then why not say so...
In any case a virtual world (The Matrix if you will) is hardly going to spring into being fully formed. There have to be steps to get there. Hopefully this book is about what steps have been tried.
What MMOGs have you tried, and what would you do differently?
I don't mean that seriously, but just before I graduated I was sitting talking with one of the professors who had taught my first year programming courses.
Over the course of the discussion we covered why they had used Miranda (functional, like Haskell) and Modula 2 in the starter courses (and indeed they'd switched from Modula to Turing the year after me).
The reasons she gave were almost word for word what you just said about 'public static void main()' and 'System.out.println'
Too much cruft too early, no matter how powerful it may be later, is bad.
Its the truth. Transcoding hurts quality. It doesn't matter if you burn first or not.
Of course, I think this illustrates the point nicely. Out of the box iTunes 4 makes it just hard enough to make mp3s to discourage more casual use.
Users with a legitimate need for mp3s (in car, mp3 player that doesn't do AAC) can get them, which is good, but it isn't one-click piracy either.
Still, blank CDs are cheap but they're not free.
Cheers. Nice talking to you :)
My limited understanding is the Darwin kernel isn't a very pure example of Mach/microkernel design in any case.
IIRC the basic idea of a microkernel is that its very small, with the functionality of a traditional kernel being implemented by a number of processes (confusingly called servers, I think?) running on top of it, with user processing running onto of those servers. All communication between these kernel servers is implemented by message passing. "Mach messages" in this case. The idea being that each server is a seperate address space, so like user processes crashes in one don't take out another, and you can swap servers in and out in a dynamic fashion (think modules, or drivers). Of course, you pay for these benefits in terms of the messaging overhead.
As I understand it Darwin is implemented as a single server process ontop of the microkernel. So effectively its a monolithic kernel server ontop of a microkernel. So that would seem to remove most of the overhead (and many of the benefits). This is all from memory though, so I may be 100% wrong.
I'd be interested in learning more about why they chose this design route. Anyone got any links? (maybe I'll look in Google later).
English comprehension clearly isn't your strongest point. The two statements I made were:
I'll give you the benefit of the doubt in that the second sentence is not as clear as it could be, but what I'm clealry saying here is that I have used NT for more than half a decade, and I have used Windows 2000 extensively, but I have not yet used Windows XP for any length of time
Infact I've been using Windows NT 4 and 2000 almost daily since some point in '97, and since NT 4 came out in '96, that's not bad. Windows NT 3.5 and XP I know less about. Where you got the idea I've not touched NT in 10 years from, I have no idea.
You obviously missed the part where I said " I mean, I wouldn't claim it [the Mac Finder] is perfect even in 10.2,". I don't disagree with you there, and even if I did, I don't see the point in insulting me with respect to my ability to use Google. You're very immature.
Now, here I agree you have a point. I think you're right: some developers are finding dealing with pre-emptive multi-tasking challenges from a UI perspective. Perhaps I don't think the issues are as large as you do, but I agree they do come up.
See how pleasant that was? I might have rated you Interesting if that's what you'd said in the first place. What I objected to was the way you tried to bluster your way to a point by setting up straw men that you can burn down easily:
Finally, grandstanding about how kernel level design issues must be the cause for all of these (poorly defined) problems, and challenging people to dare to reply to you:
I mean,
Cool. Unfortunately I've not seen much beyond Windows 2000 regularly. XP is still a bit of a mystery to me.
I wonder if you're a troll or just someone who likes to sounds clever?
Most Windows installers maximize their window, whereas all common Mac installers just use a regular window.
How many Windows users do actually minimize the installer screen though? How many just sit watching its pretty blue bar?
Oh! Now in this paragraph we can all see you're not talking about installers on the Mac after all, you're talking about you're talking about the Quicktime for Windows installer. The fact you cannot minimize it sounds annoying, true. However, as you point out you can always press Windows-M to get rid of it. Or Alt-Tab one assumes...?
So infact the set of users who are effected by this issue comes down to those people who
In other words, its a tiny annoyance in Apple's Windows installer which, while it should be corrected, has almost no effect on anyone...
Have you actually any examples, beyond vague suggestions that the Mac "File Manager" wasn't multi-threaded enough in Mac OS X 10.0 ? I mean, I wouldn't claim its perfect even in 10.2, but then I've used Windows NT and its "File Manager" for over half a decade now, and you know, it has a few threading issues too. I don't want to be rude, but other than your poorly constructed installer rant, you don't actually seem to have any examples.
Of course, you have links you could share with us to actual profiling results showing comparisons between MacOS, Windows and Linux (et al.). These show conclusively where "responsiveness differences" occur, and then proceed to demonstrate how these are surely caused by the Mach micro kernel and not any other factor like, just for example: hardware or boneheaded programing in the File Manager or GUI?
Please do post such material. It would be very interesting.
Define illegal?
Certainly you could have your contract terminated. You may even be sued for some kind of damages.
That's not the same as breaking the law.
It sounds like this would make even possessing the equipment a _crimal_ offence...
Well, interestingly enough, the config files are often bi-level... so you have:
[Code] - using logical names
[J2EE Config file] - maps logical name to "physical name"
[Vendor Config file] = maps "physical name" to parameters like hostname/port
So often even your J2EE config file can be used unaltered. What tends to happen is the J2EE config files started out with relatively few features, and the vendors added all of their stuff in the Vendor Condig File (value-added or proprietary features).
As J2EE is revised, the most commonly supported or desired features tend to move up into the J2EE Config File level. So when you upgrade to a new version you might find that things you previously had to configure on a vendor level may now be configured in an abstract portable way.
This is natural evolution. It has a cost though: the extra layer of indirection makes the initial setup more complex. Once you get it down though, its pretty easy to maintain, as a rule.
The J2EE standard doesn't cover everything you'd ever need to do to get an application off the ground.
eg, most enterprise applications allow you to connect to a database. J2EE defines a way of naming the database connection ("DataSource") with a logical name. Say "MyBigDB". This is a name bound into a JNDI tree - basically a directory. Give the directory "MyBigDB" and you get back an instance of DataSource that can connect to your database.
At some point these convenient names "MyBigDB" must be mapped to actual parameters (hostname, username, password, port number) of the database.
J2EE doesn't really specify this. Each vendor has their own config file syntax for doing this mapping.
So this is the sort of thing they mean when they say it takes "hours" to port. You find out where JBoss keeps its config files, what the syntax is, and how to map MyBigDB to the hostname etc.
Hopefully none of your code changes, its just a matter of defining mappings in config files. The more complex your application, the more points of contact with "the real world" or "the bare metal" it probably has. J2EE hides a lot, but it can't hide everything.
Hey! Earlier today this page: XServe Design included a cool joke:
I looked again, and now its gone. Spoilsports!. Did anyone cache the original? Its quoted here: At Macintouch. I swear I am not making this up!
Yes, my tone was somewhat harsh, but the exact thing I was responding to was:
"Native GUI support (Cocoa, Quartz) was non-existant. Java ran great - with CLI!"
Its very easy to read that and assume GUIs were not supported at all, or at best, were some sort of emulation. This just isn't true. They weren't based on Cocoa, true, but they were on Carbon and Quartz, which is just as "native". If it isn't, someone had better tell Apple (the Finder), Adobe (Photoshop) and Microsoft (Office) pretty quickly. All are Carbon applications.
Actually, all Swing GUIs are an emulation in some sense. Apple's is one of the most native implementations because its Aqua PLAF actually does call lots of native code (which the Sun Windows PLAF didn't last time I checked, so you could hack things and run the Window PLAF on X11 or Mac OS... but that could have changed). All that's really changed is the native layer used is now Cocoa rather than Carbon. Its not panacea. People are reporting all sorts of new GUI bugs - which is to be expected after such a huge change.
Apple's 1.3 VM was DEFINATELY NOT CLI ONLY.
It had a perfectly reasonable AWT/Swing implementation which was derived from the old Mac OS 9 implementation and ran ontop of Carbon, which means it did have the Aqua look and feel and it did run ontop of Quartz.
You can just about make that out in this diagram: http://developer.apple.com/macosx/images/sysarch_s m.gif
Now, we can talk about reimplementing AWT/Swing ontop of Cocoa rather than the crufty 20 year old foundation that is Carbon - and probably we can agree its a great thing, but it sure did take a long time. Its definately not the case that this is the first release with an Aqua GUI though!
You've been rated funny, but I wonder how many people actually got the joke. Even someone from the South of England is unlikely to get the reference, never mind an American.
OK. I'll spill. In the North of England, a Tab is a cigarette, so they do indeed cause cancer.
Books obviously don't last forever. I have a lot of first editions lying around that are painfully out of date.
To see your sample code again, you put the book back on your shelf again. Evidently you need access to it for another month... so you pay another $1.33. If you never look at book again, you've saved $38.66 by finding its not really useful for $1.33. Sounds reasonable to me. The only real risk is opportunity cost - the slot's not there for some other new book you might want to read, but as you say yourself how many new technical books do you read in a month.
I'm not disagreeing with you completely - there's a whole lot of books I appreciate owning on paper. There are also some I wish I'd never bought, because I almost never look at them. This might be worthwhile as a screening process. I mean, if you find you really never take a book off your virtual bookshelf, you might as well buy a paper copy. If you read it through once and never look at it again, you've saved a lot of money.
Then again, there's always the chance of a second edition... and searchable technical books looks like a real plus to me (sometimes I can't even remember which book a code example is in, much less find it in the index!).
I can stand reading documentation onscreen. A good eBook reader would be better though.
You do have it straight, though actually, Mozilla itself will soon be dropping Classic (OS 9) support.
At that point they'll switch to a Unix back end with a Carbon front end. While a Cocoa port of the front end would be nice, its quite large, and the performance gains most likely lie in moving the back end to the Unix back end.
Chimera is not a Cocoa port of the entire Mozilla front end UI - its a completely seperate UI for "just the browser". Sort of like Phoenix, but more like Galeon or KMellon, because it doesn't use XUL.
Interestingly, one could presumably make a version of Chimera that used Apple's WebCore (the Safari rendering engine), and indeed Apple could always take the Safari UI and use Gecko (the Mozilla rendering engine) at some point in the future. I don't expect to see either happen though!
Picture the scene, its the mid-80s. Apple engineers want a way to network their dinky 9" screen toaster macs. All they have is a serial port, and almost no one has heard of Ethernet.
More importantly, the wife (landlord or whoever) is not going to stand for rewiring the house with some computer nonsense.
Solution: AppleTalk networking over LocalTalk cabling. ie, use the existing phone sockets and cabling to send data. By modern standards it crawls, but it works well and is still in use today (by some unfortunate souls).
Almost 20 years later you have HomePNA. There aren't many new ideas in this world.
>>Brin
>>This yearning makes sense if you remember that >>arbitrary lords and chiefs did rule us for 99.44 >>percent of human existence. It's only been 200 >>years or so -- an eye blink -- that "scientific >>enlightenment" began waging its rebellion against >>the nearly universal pattern called feudalism
>pVoid
>Not to break it to you Einstein, but democracy was >invented in ancient Greece. That's not a couple of >hundred years, it's a couple of thousand years... >just about as old as christianity itself.
Well, while we're busy being irratated....
Many people have already pointed out Greek democracy was hardly the same thing that we have now. I'll point out that you've seriously missed the point:
Brin is saying that for 200 years some reasonable proportion of the world has lived in a democracy. The fact a few Greeks had something like it before the birth of Christ is irrelevant - it was almost forgotten and certainly never much practised in the next 2000 years or so. He didn't say it hadn't been INVENTED, only that it wasn't USED.
>>Timidly at first, guilds and townsfolk rallied >>together and lent their support to kings, thereby >>easing oppression by local lords.
>Does he actually have proof of this, or is he >using the LoTR as a template?
I'll refer you to the history of mainland Europe, in particular you might like to read about what's now Belgium for a start.
>This guy hasn't read the Silmarillion probably.
I have. And the first 10 volumes of the History of Middle Earth, including the poetry (eek!) There's some merit in what you say, but its much more complex.
> It seems to me he's the typical Hollywoodist he >criticizes in his own essay: trying to attract >attention by shock value.
Actually, he's a widely respected sci fi author. He's been writing on these themes for several years. If he's using shock value its to needle you into thinking about the ideas he presents. You can disagree, of course, but that seems to be his motive to me.
(who couldn't bring himself to read beyond the first page---moderate accordingly)
I'll reply instead. Brin is a thinker. He doesn't necessarily give away his entire idea in the first paragraph.
Do yourself a favour and read the rest. Then you can decide if there's merit in the point he's actually making, rather than what you think he's saying.
Unless you're too lazy.