Great idea. However, I have yet to see any monitor which is even capable of those resolutions at the sizes you have indicated. I don't know of any 15" monitors which can do more than 1024x768, and I can't even get my 17" higher than that (never mind that it says quite plainly on the box that it should be possible). All of the 19" monitors I've found can't do more than 1280, and the 21-inchers can't do more than 1600.
Look, here's the REAL reason Jar-Jar sounded Jamaican, and it's actually totally innocent.
You see, the man who voiced Jar-Jar grew up in Jamaica. He was actually using his own natural voice, with only slight exaggeration (which he deemed appropriate for a comic sidekick).
I still wish Gnome and KDE could agree on a common windowmanager support API. Then people wouldn't have to write in support for both; support one and you support the other. The two really should cooperate on more stuff (I'd say on everything but toolkits, but I know that's a bit extreme).
Maybe, at some point in the past, in a much older version of the client and server software that no longer run anymore, this was true. Maybe.
Perhaps in an older version of the client software that no longer ran anymore, this would be true.
Just one problem: all versions of the AOL software still run. I believe I still have the oldest AOL frontend (version 1.0 for MacOS; it should be noted that AOL was originally Mac-only unless you count Q-Link which was C64-only). Last time I ran it, it worked fine (and allowed you to enter fake credit card numbers as long as they were theoretically valid, yet another security hole).
That's just it. Perhaps in the 4.0 version, some of these security holes were closed up. But AOL prides itself on its backward-compatibility, and all of the security holes present in the older versions are still valid. There's a price to pay for the exploits: you miss out on the features of the new software. But they all still run fine.
This just isn't true. Sure, the press reports that things are found now and then, and there may have been problems in the past, but his posting about the so-called "client-based security model" is just plain incorrect, wrong, and downright clueless.
One: this one never got into the press. Two: I'm afraid it's quite true. It was true then, and it's true now. If you have an old copy of AOL 2.6 I believe I still have the patch lying around; the patch is useless now (though I'd imagine it would still run, but what's the point?) but I'll show you if you like. Three: You're right, a client-based security model is incorrect, wrong, and downright clueless. But remember who we're talking about here.
If he really knew what he was talking about, he'd have been able to exploit any security hole --which he admits he was not able to do.
This was years ago, before I knew how to program (much less hack Mac program code using nothing but ResEdit). Just because I know how a program works doesn't mean I can write a program to exploit security holes, much less hack another program to do it. Especially when I don't know how to program, which I didn't back then.
Look, I know what I saw; I used this program for a while, in fact. And I don't appreciate being called clueless for bringing up an old AOL hack which likely invokes nostalgia in more than one Slashdotter.
Besides, what does it have to do with AOLserver at all?
Directly, nothing. But consider the following: one, the server's name is confusingly worded, such that people often think it's the server for AOL's content. Two, people have been clamoring for AOL to Open-Source their stuff. Three, AOL can't do this, and there's actually a damn good reason for it, namely bad software design (which I suppose isn't a good reason, but it's a valid one nonetheless).
I always forget that it's a web server, not their own content server. I get my hopes up that AOL's gone Open-Source, and then it's a big letdown.
Then again, AOL can't Open-Source its stuff; if it did it would die withim days. No, this is not anti-Open-Source FUD: let me explain. You see, most (if not all) of AOL's security features are implemented solely in the client. This means that if you figure out how to access AOL via a terminal (it IS possible, but exceedingly difficult; I've never managed it myself) you essentially have admin access, minus the pretty icons and such, no matter what screen name you use. You still can't get other people's passwords, but who cares; other than that it's more or less like having root access to AOL (if such a thing existed).
In other words, if you Open-Source the client, it's a trivial matter to remove all of the readblocks in the client, recompile, and have an "instant admin" client. And you know all of the AOL lamers would have a field day with that.
The Mac (or former Mac users) here who used to be on AOL might remember a program called AOL4Free (made by a guy calling himself Happy Hardcore). This nifty little hack undid one of these locks in the client... the one which told the AOL server to bill the user (this was back in the days before AOL went flat-rate). The way it did this, however, tended to overload the server with a certain kind of packet. When the program got popular, the server eventually ground to a chronic halt; although AOL doesn't like people to know about it this was the real reason AOL was so slow until their server upgrade of a few years back; Mac users were getting free time and flooding the server as a side effect (I don't think a Windoze equivalent was ever made).
The program eventually started undoing other locks, allowing the user access to admin-only areas (such as the fabled "Center of the Earth" chatroom, which at the time had double the capacity of normal chatrooms). The guides eventually had to move out of that chatroom, and went to one called "Wonderland"; Hardcore cracked that one too, and I don't even know where the guides hang out now.
So you see, in AOL's case, Open-Sourcing the client really does mean death. But they have only themselves to blame for not designing their software right in the first place.
Consider the Gnome/KDE sflamewars. Those of us who kept our heads all wanted to see the two cooperate, but I don't think anyone honestly believed it would ever happen.
Therefore, two other things that aren't likely to happen but should: M$ going bankrupt and MacOS getting a bit of respect among the geek community.
This is a step in the right direction (a common windowmanager support API would be nice also).
It's not going the whole way, but that's to be expected; these things are usually taken in small steps. It's the sort of thing which should be encouraged; the more interoperable these DE's become the better for everyone.
I think Apple can win this one. I'm pretty certain they trademarked that case design (something which is perfectly within their rights; Coca-Cola did it with the classic "Coke bottle" we all know and love). In this case, both companies have violated that trademark pretty badly; have you seen pictures of these things? Exact knock-offs, right down to the little ridges on the top of the case (no Apple logos of course). They're even offering them in the same colors, though they're naming them after gemstones instead of flavors.
I applaud Apple for this one. This isn't software, and it certainly isn't look-and-feel. It's a company trying to make money off of Apple's success with the iMac by making an inferior copy. Sorta like Windows only even more obvious.
And the hell of it is, they got it wrong. The measure isn't completely accurate. I suppose that puts it up near the Farenheit scale in the Greatest Scientific Bloopers of All Time list.
Don't quote me on this, but I believe that the French had their hand in the imperial system as well. It depends on what you're measuring. The Farenheit scale (one of the greatest scientific bloopers of all time, due to the fact that 0 is where seawater freezes and 100 is supposed to be human body temperature but the test subject had a fever that day) is German, I believe (or was it Austrian?) The standard for time goes waaaaaaay back, to ancient Persia if I'm not mistaken (and even the French don't dispute that standard; people wouldn't stand for that one). The weights are mostly English, I think. However, distances and areas come from all over the place (the acre is from ancient Mesopotamia, of all places), and I believe several of them come from France (I'm pretty sure the yard does).
Interesting, since the French are also credited with the metric system (and adopted it during the French Revolution not so much for its scientific value as for its ability to piss off the aristocracy by removing the lengths of their various body parts from the standard of measure; this is why they also completely rewrote the calendar).
Regardless, it appears Bill Gates has infiltrated the French government, since they're trying to Embrace and Extend the standard for cartography and time zone measurement.
OS X will basically only run on Apple G3 hardware which is only a small part of the overall PPC hardware that is there already. It is in no way POSIX compliant - even apple have said that it will not be made to be so, therefore you can't just use the source luke.
Reading this, I have to wonder if you have any idea just what POSIX is. All evidence points to no. Therefore, a little explanation is in order:
POSIX is a standard for operating systems. It has absolutely nothing to do with hardware, unlike what you seem to be implying. When it was written, it was based off of Unix. To be considered "compliant" it must pass a rigid set of hideously expensive tests and get certified and all of that good stuff.
You'll be interested to know that Linux isn't POSIX-compliant either. It "aims toward" compliance. Guess what: so does OSX. Apple has said they're not going to bother getting it certified, that's true. Last I checked, neither was the Linux crowd.
What does that leave us with? Something not unlike Mesa. You can't call Mesa OpenGL, since it's never been officially certified, but let's face it: for all intents and purposes, it's OpenGL. Likewise with Linux and OSX: You can't call them POSIX-compliant, because they were never certified as such and likely never will be, but both are striving to (and eventually will) achieve that goal.
As for that "use the source Luke" bit, I'm not sure exactly where that came from. I sincerely hope you don't mean that it doesn't qualify as Open-Source because it's not POSIX-compliant (and the rest of the way your article reads, this seems highly likely). POSIX has nothing to do with the openness (or lack thereof) of one's source. If you mean compiling POSIX programs out of the box, prepare for another revelation: it's about as easy to do with OSX/Darwin as it is with Linux; I'll be happy to point you to more than a few programs which have already been ported over.
This means that OS X is set up as a commercial venture.... you have to pay for the software you want to run.
No one ever pretended otherwise. Not only that, but in case you haven't noticed, Open-Source software can and does exist for proprietary platforms. Also, for the last time, Open-Source does not necessarily mean zero-cost.
Sure apache compiles out of the box... now... only after the apache group ported it accross.
Actually, last I heard it was Apple who did that port, not the Apache group.
In my experience it looks good runs well but it is not an open-source solution.
Why not? Looks pretty Open-Source to me. It seems you're still a little fuzzy on just what Open-Source is.
The other point about OS X is that it is based on the mach kernel so it inherently has the same performance issues as MK.
I hate to say it, but you're wrong. I've used both Darwin and the OSX Developer Preview. I see no horrendous speed issues such as you describe. In fact, I've found it quite fast.
OK, perhaps I'm just misinterpreting what you've written. It doesn't look that way, though. If I have, I apologize.
Also, the standard disclaimer when I go to rebut a post: This is not intended as a flame or as flamebait; please do not take it as such.
They were going to give this thing an NC-17 solely on the basis of swear words? When's the last time anyone did that? (Come to think of it, I don't think it's ever been done).
Then again, count in the inevitable Kenny death and Chef's singing and I suppose you might have enough that's strong enough to get it an R, but I think there was something else going on here. I'd imagine the ratings board was afraid of our friends the zealots screaming at them (considering that they were talking about the "corruption of children" that seems likely; I've never seen anyone but the zealots use that term). They already hate the series, so of course they'd go after the movie (both of these being thanks to their own rather blind assertion that animation isn't a medium but a genre).
Oh, yes, I'll be seeing this one. In fact, I can show this article to more than a few of my friends and it'll probably convince them to see it even though they hate the series (just to keep the zealots from having their way).
You're right; you can't build a computer smaller than the smallest computer core. And we all know, robots by definition need a computer to tell them what to do. So if you want a robot smaller than a computer, move the computer outside the 'bot.
My guess is that the first nanorobots (nanites, nanobots, whatever) won't contain their own programming at all. All they'll have is a rudimentary instruction set; the instructions will then be fed by a larger, external device (probably communicating via radio).
The "enzyme model" (each 'bot works by interacting with individual molecules) is another interesting approach, but not one that I'd think would be practical with today's technology. Plus consider that it would take many 'bots working in tandem to get anything done.
I like the way it's written, but what are you talking about? I get the feeling the other posters here have misunderstood your post a bit; I simply don't understand it at all. Could you possibly clarify things?
Actually, diamonds would be an excellent choice, were it not for the DeBeers family. You see, the hell of it is, diamonds aren't even all that rare. It's just that the DeBeers family owns all of the known mines. They exercise monopoly power in ways which would make Bill Gates look like RMS, and that's why diamonds are so expensive.
Diamonds aren't that tough to manufacture in labs, either, believe it or not (after all, diamonds are just carbon, which is plentiful; add a bit of boron and you get one hell of a semiconductor).
However, you still have one major problem: speed. Consider the following: CD/DVD has made creat strides in the past years speed-wise, but they're still much slower than a hard drive. And that's only on 2-dimensional media. Add a third dimension, and you get something which is absolutely wonderful for backups, but not for general use.
Though I'll be the first to admit, the day I can use Trek-like "isolinear chips" will be quite cool indeed...
Actually, it's another abuse of the patent system. This one is called a "design patent" and it really does simply put a patent on look and feel. Apple's got loads of them, including Platinum, Hi-Tech, Gizmo, Drawing Board (I think), and loads of others that no one really knows why they have since even Apple doesn't use them.
If I could remember the patent numbers I'd post links to them. In any case, I'd imaging M$ has patents on the look and feel of Win95 and 98 too (though why would you want to patent such bad stuff?)
Either way, you're discounting the possibility that perhaps they licensed the looks from Apple and M$. Unlikely, to be sure, but possible (little-known fact: Apple actually had purchased licenses for all the GUI stuff they took from Xerox. M$ did not have licenses for what it took from Apple).
Anyway, that's the thing there. Troll might get sued for it. Then again, I don't think either Apple or M$ will bother to do it.
We're not by any means ready for holodecks yet. But this is certainly another step towards that...
Step 1 was photography. Step 2 was holography on those little silver things. Step 3 was the "matter laser" (so far working but still experimental, it works similarly to a laser but with matter waves) Step 4 was the 3-D camera. Step 5 is 3-D television; getting it working without glasses and whatnot. Step 6 is synthesizing matter with the matter laser. The last step is doing 3-D TV with the matter laser, allowing for solid holograms.
So we still have a way to go, but nevertheless this is a significant advance.
Re:Well, those are not really themes
on
qt 2.0 released
·
· Score: 2
Actually, they still count as themes.
As I understand it, a "theme" is simply one "look" which can be set once such that all apps which support that theme style will then use it.
For GTK, these are Default, Redmond95, Notif, and Pixmap.
This also means that the "themes" we commonly see at gtk.themes.org are, strictly speaking, usually not themes in the strictest sense of the word; rather they are configurations of the Pixmap theme plus the necessary graphics to make the configuration run. I suppose "skin" would be a better term for those types of themes: a GUI widget configuration for one program, which in this case is the Pixmap theme. Because that program is itself a theme, Pixmap skins act like themes.
"Themes" sound cooler than "skins" anyway:)
Re:Well, Qt2.0 has been through extensive beta
on
qt 2.0 released
·
· Score: 2
Did I use Gnome 1.0? Nope. Matter of fact, I didn't pick up Gnome till about 1.0.6 or so.
As for Qt getting out of beta, there's one thing. Lots of people don't use betas very much, but everyone immediately grabs for the 1.0 releases. It's as though your testing pool suddenly quintupled. THey'll find bugs you missed the first time, guaranteed. Even the Linux kernel isn't immune to this; if I remember correctly 2.2.1 came out only a day after 2.2.
I won't be downloading it (not because of any GTK zealotry; I'm waiting for 2.0.1 and all the inevitable bug fixes the Troll guys missed). Besides, I have a few questions concerning themes:
1) How compatible are the themes with those from GTK (at least for pixmap-based themes; I know the engine-based themes have no hope of compatibility)? It'd be nice if I could use the same theme for all my apps, and since work on Qt's themes didn't even start until after GTK's was cemented the only reason to make them incompatible is for incompatibility's sake.
2) Assume that GTK and Qt themes are incompatible (which is likely, unfortunately). How easy is it to convert the themes between toolkits? Might we be seeing a program in the future to do this?
3) Suppose the second isn't possible. Might it be possible for either toolkit to eventually gain the ability to read in the other's theme format?
As you can see, my biggest concern is interoperability between the two. While I don't have any Qt/KDE apps (never saw the need for any of the current batch, again I don't consider myself a zealot) it'd really be nice to use them seamlessly with GTK/Gnome apps (this is also why I'm pushing for a common desktop API which both KDE and Gnome could support, so a developer could write the code once and support both DE's. XDND is a start, but drag-and-drop isn't the only thing which needs the help a common API gives).
1) It's unlike InfoWorld to print such an unprofessionally-written, poorly-researched piece. 2) It doesn't seem right that the inventor of Ethernet, of all people, would tout "23/6 availability" as a good thing. This guy knows that computers can do better than that (and often do; even a properly-maintained MacOS machine can outdo NT in stability and security). 3) When it comes to "ignoring 30 years of innovation" Metcalfe may have a point where interface is concerned (I'm impressed with the strides Gnome and KDE have made in this area, but one can only do so much with such comparatively ancient technologies as X and the command-line) but he doesn't seem to get the idea that Linux is quite up-to-date in most areas, and with the recent Open-Sourcing of such things as XFS it'll be catching up in even more stuff. 4) Going back to the lack of professionalism in the article: do you really think he'd do that? One doesn't stay in his position for as long as he has by being the sort of person who'd write that. 5) Win2K doesn't have a chance. Linux, BeOS, and OSX will all stomp it flat (especially since two of them are out already, and the third, OSX, will likely be at least a year before Win2K ever sees a store shelf, knowing Microsoft's punctuality or lack thereof). What happens after that? I don't know. I hope the three can coexist harmoniously (I know it's possible) but I doubt that will happen.
I'm having trouble believing that this article is real. It strikes me as odd that they would print an article so unprofessionally written.
It is, however, partially right on one of its points: the bit about ignoring 30 years of innovation. Not in terms of under-the-hood stuff, mind you; Linux is reasonably up-to-date with that (and with some of the latest things, like XFS and the others, it will be up-to-date in even more).
But it lags sorely behind in interface. The default command-line does ignore 30 years, and to be honest I have difficulty believing that any operating system still carries such an archaism. X ignores 15 years, and is marginally better (I'll admit that I'm impressed with what the Gnome and KDE projects are actually managing to do with it) but it falls into more than a few traps (which can be expected; even at the time of X's invention superior GUI's, such as NeWS, were available, but were scoffed at for some reason). More powerful interfaces have been around for years. I'll be among the first to check Berlin out (once it's in a usable state) for this very reason.
But hey, I'm a Mac and Linux user; I'd been spoiled by usable interfaces for years before switching to Linux. And if I do anything more I'll head off into a flamebait rant (which I honestly don't intend to do), so I'll shut up about it here.
Regardless, the article is for the most part just unprofessional FUD, and not something to be taken particularly seriously.
Slashdot Mirror
15" = 1152x900
17" = 1280x1024
19" = 1600x1200
21" = 1880x1440
Great idea. However, I have yet to see any monitor which is even capable of those resolutions at the sizes you have indicated. I don't know of any 15" monitors which can do more than 1024x768, and I can't even get my 17" higher than that (never mind that it says quite plainly on the box that it should be possible). All of the 19" monitors I've found can't do more than 1280, and the 21-inchers can't do more than 1600.
Look, here's the REAL reason Jar-Jar sounded Jamaican, and it's actually totally innocent.
You see, the man who voiced Jar-Jar grew up in Jamaica. He was actually using his own natural voice, with only slight exaggeration (which he deemed appropriate for a comic sidekick).
I still wish Gnome and KDE could agree on a common windowmanager support API. Then people wouldn't have to write in support for both; support one and you support the other. The two really should cooperate on more stuff (I'd say on everything but toolkits, but I know that's a bit extreme).
Maybe, at some point in the past, in a much older version of the client and server software that no longer run anymore, this was true. Maybe.
Perhaps in an older version of the client software that no longer ran anymore, this would be true.
Just one problem: all versions of the AOL software still run. I believe I still have the oldest AOL frontend (version 1.0 for MacOS; it should be noted that AOL was originally Mac-only unless you count Q-Link which was C64-only). Last time I ran it, it worked fine (and allowed you to enter fake credit card numbers as long as they were theoretically valid, yet another security hole).
That's just it. Perhaps in the 4.0 version, some of these security holes were closed up. But AOL prides itself on its backward-compatibility, and all of the security holes present in the older versions are still valid. There's a price to pay for the exploits: you miss out on the features of the new software. But they all still run fine.
This just isn't true. Sure, the press reports that things are found now and then, and there may have been problems in the past, but his posting about the so-called "client-based security model" is just plain incorrect, wrong, and downright clueless.
One: this one never got into the press.
Two: I'm afraid it's quite true. It was true then, and it's true now. If you have an old copy of AOL 2.6 I believe I still have the patch lying around; the patch is useless now (though I'd imagine it would still run, but what's the point?) but I'll show you if you like.
Three: You're right, a client-based security model is incorrect, wrong, and downright clueless. But remember who we're talking about here.
If he really knew what he was talking about, he'd have been able to exploit any security hole --which he admits he was not able to do.
This was years ago, before I knew how to program (much less hack Mac program code using nothing but ResEdit). Just because I know how a program works doesn't mean I can write a program to exploit security holes, much less hack another program to do it. Especially when I don't know how to program, which I didn't back then.
Look, I know what I saw; I used this program for a while, in fact. And I don't appreciate being called clueless for bringing up an old AOL hack which likely invokes nostalgia in more than one Slashdotter.
Besides, what does it have to do with AOLserver at all?
Directly, nothing. But consider the following: one, the server's name is confusingly worded, such that people often think it's the server for AOL's content. Two, people have been clamoring for AOL to Open-Source their stuff. Three, AOL can't do this, and there's actually a damn good reason for it, namely bad software design (which I suppose isn't a good reason, but it's a valid one nonetheless).
I always forget that it's a web server, not their own content server. I get my hopes up that AOL's gone Open-Source, and then it's a big letdown.
Then again, AOL can't Open-Source its stuff; if it did it would die withim days. No, this is not anti-Open-Source FUD: let me explain. You see, most (if not all) of AOL's security features are implemented solely in the client. This means that if you figure out how to access AOL via a terminal (it IS possible, but exceedingly difficult; I've never managed it myself) you essentially have admin access, minus the pretty icons and such, no matter what screen name you use. You still can't get other people's passwords, but who cares; other than that it's more or less like having root access to AOL (if such a thing existed).
In other words, if you Open-Source the client, it's a trivial matter to remove all of the readblocks in the client, recompile, and have an "instant admin" client. And you know all of the AOL lamers would have a field day with that.
The Mac (or former Mac users) here who used to be on AOL might remember a program called AOL4Free (made by a guy calling himself Happy Hardcore). This nifty little hack undid one of these locks in the client... the one which told the AOL server to bill the user (this was back in the days before AOL went flat-rate). The way it did this, however, tended to overload the server with a certain kind of packet. When the program got popular, the server eventually ground to a chronic halt; although AOL doesn't like people to know about it this was the real reason AOL was so slow until their server upgrade of a few years back; Mac users were getting free time and flooding the server as a side effect (I don't think a Windoze equivalent was ever made).
The program eventually started undoing other locks, allowing the user access to admin-only areas (such as the fabled "Center of the Earth" chatroom, which at the time had double the capacity of normal chatrooms). The guides eventually had to move out of that chatroom, and went to one called "Wonderland"; Hardcore cracked that one too, and I don't even know where the guides hang out now.
So you see, in AOL's case, Open-Sourcing the client really does mean death. But they have only themselves to blame for not designing their software right in the first place.
However, you cannot deny the geekiness of having an entire 8-machine Beowulf cluster on one motherboard.
Consider the Gnome/KDE sflamewars. Those of us who kept our heads all wanted to see the two cooperate, but I don't think anyone honestly believed it would ever happen.
Therefore, two other things that aren't likely to happen but should: M$ going bankrupt and MacOS getting a bit of respect among the geek community.
This is a step in the right direction (a common windowmanager support API would be nice also).
It's not going the whole way, but that's to be expected; these things are usually taken in small steps. It's the sort of thing which should be encouraged; the more interoperable these DE's become the better for everyone.
I think Apple can win this one. I'm pretty certain they trademarked that case design (something which is perfectly within their rights; Coca-Cola did it with the classic "Coke bottle" we all know and love). In this case, both companies have violated that trademark pretty badly; have you seen pictures of these things? Exact knock-offs, right down to the little ridges on the top of the case (no Apple logos of course). They're even offering them in the same colors, though they're naming them after gemstones instead of flavors.
I applaud Apple for this one. This isn't software, and it certainly isn't look-and-feel. It's a company trying to make money off of Apple's success with the iMac by making an inferior copy. Sorta like Windows only even more obvious.
And the hell of it is, they got it wrong. The measure isn't completely accurate. I suppose that puts it up near the Farenheit scale in the Greatest Scientific Bloopers of All Time list.
Don't quote me on this, but I believe that the French had their hand in the imperial system as well. It depends on what you're measuring. The Farenheit scale (one of the greatest scientific bloopers of all time, due to the fact that 0 is where seawater freezes and 100 is supposed to be human body temperature but the test subject had a fever that day) is German, I believe (or was it Austrian?) The standard for time goes waaaaaaay back, to ancient Persia if I'm not mistaken (and even the French don't dispute that standard; people wouldn't stand for that one). The weights are mostly English, I think. However, distances and areas come from all over the place (the acre is from ancient Mesopotamia, of all places), and I believe several of them come from France (I'm pretty sure the yard does).
Interesting, since the French are also credited with the metric system (and adopted it during the French Revolution not so much for its scientific value as for its ability to piss off the aristocracy by removing the lengths of their various body parts from the standard of measure; this is why they also completely rewrote the calendar).
Regardless, it appears Bill Gates has infiltrated the French government, since they're trying to Embrace and Extend the standard for cartography and time zone measurement.
OS X will basically only run on Apple G3 hardware which is only a small part of the overall PPC hardware that is there already. It is in no way POSIX compliant - even apple have said that it will not be made to be so, therefore you can't just use the source luke.
.... you have to pay for the software you want to run.
... now ... only after the apache group ported it accross.
Reading this, I have to wonder if you have any idea just what POSIX is. All evidence points to no. Therefore, a little explanation is in order:
POSIX is a standard for operating systems. It has absolutely nothing to do with hardware, unlike what you seem to be implying. When it was written, it was based off of Unix. To be considered "compliant" it must pass a rigid set of hideously expensive tests and get certified and all of that good stuff.
You'll be interested to know that Linux isn't POSIX-compliant either. It "aims toward" compliance. Guess what: so does OSX. Apple has said they're not going to bother getting it certified, that's true. Last I checked, neither was the Linux crowd.
What does that leave us with? Something not unlike Mesa. You can't call Mesa OpenGL, since it's never been officially certified, but let's face it: for all intents and purposes, it's OpenGL. Likewise with Linux and OSX: You can't call them POSIX-compliant, because they were never certified as such and likely never will be, but both are striving to (and eventually will) achieve that goal.
As for that "use the source Luke" bit, I'm not sure exactly where that came from. I sincerely hope you don't mean that it doesn't qualify as Open-Source because it's not POSIX-compliant (and the rest of the way your article reads, this seems highly likely). POSIX has nothing to do with the openness (or lack thereof) of one's source. If you mean compiling POSIX programs out of the box, prepare for another revelation: it's about as easy to do with OSX/Darwin as it is with Linux; I'll be happy to point you to more than a few programs which have already been ported over.
This means that OS X is set up as a commercial venture
No one ever pretended otherwise. Not only that, but in case you haven't noticed, Open-Source software can and does exist for proprietary platforms. Also, for the last time, Open-Source does not necessarily mean zero-cost.
Sure apache compiles out of the box
Actually, last I heard it was Apple who did that port, not the Apache group.
In my experience it looks good runs well but it is not an open-source solution.
Why not? Looks pretty Open-Source to me. It seems you're still a little fuzzy on just what Open-Source is.
The other point about OS X is that it is based on the mach kernel so it inherently has the same performance issues as MK.
I hate to say it, but you're wrong. I've used both Darwin and the OSX Developer Preview. I see no horrendous speed issues such as you describe. In fact, I've found it quite fast.
OK, perhaps I'm just misinterpreting what you've written. It doesn't look that way, though. If I have, I apologize.
Also, the standard disclaimer when I go to rebut a post: This is not intended as a flame or as flamebait; please do not take it as such.
They were going to give this thing an NC-17 solely on the basis of swear words? When's the last time anyone did that? (Come to think of it, I don't think it's ever been done).
Then again, count in the inevitable Kenny death and Chef's singing and I suppose you might have enough that's strong enough to get it an R, but I think there was something else going on here. I'd imagine the ratings board was afraid of our friends the zealots screaming at them (considering that they were talking about the "corruption of children" that seems likely; I've never seen anyone but the zealots use that term). They already hate the series, so of course they'd go after the movie (both of these being thanks to their own rather blind assertion that animation isn't a medium but a genre).
Oh, yes, I'll be seeing this one. In fact, I can show this article to more than a few of my friends and it'll probably convince them to see it even though they hate the series (just to keep the zealots from having their way).
You're right; you can't build a computer smaller than the smallest computer core. And we all know, robots by definition need a computer to tell them what to do. So if you want a robot smaller than a computer, move the computer outside the 'bot.
My guess is that the first nanorobots (nanites, nanobots, whatever) won't contain their own programming at all. All they'll have is a rudimentary instruction set; the instructions will then be fed by a larger, external device (probably communicating via radio).
The "enzyme model" (each 'bot works by interacting with individual molecules) is another interesting approach, but not one that I'd think would be practical with today's technology. Plus consider that it would take many 'bots working in tandem to get anything done.
I like the way it's written, but what are you talking about? I get the feeling the other posters here have misunderstood your post a bit; I simply don't understand it at all. Could you possibly clarify things?
Actually, diamonds would be an excellent choice, were it not for the DeBeers family. You see, the hell of it is, diamonds aren't even all that rare. It's just that the DeBeers family owns all of the known mines. They exercise monopoly power in ways which would make Bill Gates look like RMS, and that's why diamonds are so expensive.
Diamonds aren't that tough to manufacture in labs, either, believe it or not (after all, diamonds are just carbon, which is plentiful; add a bit of boron and you get one hell of a semiconductor).
However, you still have one major problem: speed. Consider the following: CD/DVD has made creat strides in the past years speed-wise, but they're still much slower than a hard drive. And that's only on 2-dimensional media. Add a third dimension, and you get something which is absolutely wonderful for backups, but not for general use.
Though I'll be the first to admit, the day I can use Trek-like "isolinear chips" will be quite cool indeed...
that doesn't explain the HTTP perf diff though... Is IIS also in the kernel on NT?
Consider who you're talking about; I'd consider that while IIS itself probably isn't in the kernel, it access top-secret M$ stuff which is.
also, why can't we do a similar multi-threaded implementation on Linux?
I don't know. It probably is possible; it just hasn't been done yet. I'd consider these tests to be a sign that it needs doing.
Actually, it's another abuse of the patent system. This one is called a "design patent" and it really does simply put a patent on look and feel. Apple's got loads of them, including Platinum, Hi-Tech, Gizmo, Drawing Board (I think), and loads of others that no one really knows why they have since even Apple doesn't use them.
If I could remember the patent numbers I'd post links to them. In any case, I'd imaging M$ has patents on the look and feel of Win95 and 98 too (though why would you want to patent such bad stuff?)
Either way, you're discounting the possibility that perhaps they licensed the looks from Apple and M$. Unlikely, to be sure, but possible (little-known fact: Apple actually had purchased licenses for all the GUI stuff they took from Xerox. M$ did not have licenses for what it took from Apple).
Anyway, that's the thing there. Troll might get sued for it. Then again, I don't think either Apple or M$ will bother to do it.
We're not by any means ready for holodecks yet. But this is certainly another step towards that...
Step 1 was photography.
Step 2 was holography on those little silver things.
Step 3 was the "matter laser" (so far working but still experimental, it works similarly to a laser but with matter waves)
Step 4 was the 3-D camera.
Step 5 is 3-D television; getting it working without glasses and whatnot.
Step 6 is synthesizing matter with the matter laser.
The last step is doing 3-D TV with the matter laser, allowing for solid holograms.
So we still have a way to go, but nevertheless this is a significant advance.
Actually, they still count as themes.
:)
As I understand it, a "theme" is simply one "look" which can be set once such that all apps which support that theme style will then use it.
For GTK, these are Default, Redmond95, Notif, and Pixmap.
This also means that the "themes" we commonly see at gtk.themes.org are, strictly speaking, usually not themes in the strictest sense of the word; rather they are configurations of the Pixmap theme plus the necessary graphics to make the configuration run. I suppose "skin" would be a better term for those types of themes: a GUI widget configuration for one program, which in this case is the Pixmap theme. Because that program is itself a theme, Pixmap skins act like themes.
"Themes" sound cooler than "skins" anyway
Did I use Gnome 1.0? Nope. Matter of fact, I didn't pick up Gnome till about 1.0.6 or so.
As for Qt getting out of beta, there's one thing. Lots of people don't use betas very much, but everyone immediately grabs for the 1.0 releases. It's as though your testing pool suddenly quintupled. THey'll find bugs you missed the first time, guaranteed. Even the Linux kernel isn't immune to this; if I remember correctly 2.2.1 came out only a day after 2.2.
I won't be downloading it (not because of any GTK zealotry; I'm waiting for 2.0.1 and all the inevitable bug fixes the Troll guys missed). Besides, I have a few questions concerning themes:
1) How compatible are the themes with those from GTK (at least for pixmap-based themes; I know the engine-based themes have no hope of compatibility)? It'd be nice if I could use the same theme for all my apps, and since work on Qt's themes didn't even start until after GTK's was cemented the only reason to make them incompatible is for incompatibility's sake.
2) Assume that GTK and Qt themes are incompatible (which is likely, unfortunately). How easy is it to convert the themes between toolkits? Might we be seeing a program in the future to do this?
3) Suppose the second isn't possible. Might it be possible for either toolkit to eventually gain the ability to read in the other's theme format?
As you can see, my biggest concern is interoperability between the two. While I don't have any Qt/KDE apps (never saw the need for any of the current batch, again I don't consider myself a zealot) it'd really be nice to use them seamlessly with GTK/Gnome apps (this is also why I'm pushing for a common desktop API which both KDE and Gnome could support, so a developer could write the code once and support both DE's. XDND is a start, but drag-and-drop isn't the only thing which needs the help a common API gives).
This can't be a real article. Why?
1) It's unlike InfoWorld to print such an unprofessionally-written, poorly-researched piece.
2) It doesn't seem right that the inventor of Ethernet, of all people, would tout "23/6 availability" as a good thing. This guy knows that computers can do better than that (and often do; even a properly-maintained MacOS machine can outdo NT in stability and security).
3) When it comes to "ignoring 30 years of innovation" Metcalfe may have a point where interface is concerned (I'm impressed with the strides Gnome and KDE have made in this area, but one can only do so much with such comparatively ancient technologies as X and the command-line) but he doesn't seem to get the idea that Linux is quite up-to-date in most areas, and with the recent Open-Sourcing of such things as XFS it'll be catching up in even more stuff.
4) Going back to the lack of professionalism in the article: do you really think he'd do that? One doesn't stay in his position for as long as he has by being the sort of person who'd write that.
5) Win2K doesn't have a chance. Linux, BeOS, and OSX will all stomp it flat (especially since two of them are out already, and the third, OSX, will likely be at least a year before Win2K ever sees a store shelf, knowing Microsoft's punctuality or lack thereof). What happens after that? I don't know. I hope the three can coexist harmoniously (I know it's possible) but I doubt that will happen.
I'm having trouble believing that this article is real. It strikes me as odd that they would print an article so unprofessionally written.
It is, however, partially right on one of its points: the bit about ignoring 30 years of innovation. Not in terms of under-the-hood stuff, mind you; Linux is reasonably up-to-date with that (and with some of the latest things, like XFS and the others, it will be up-to-date in even more).
But it lags sorely behind in interface. The default command-line does ignore 30 years, and to be honest I have difficulty believing that any operating system still carries such an archaism. X ignores 15 years, and is marginally better (I'll admit that I'm impressed with what the Gnome and KDE projects are actually managing to do with it) but it falls into more than a few traps (which can be expected; even at the time of X's invention superior GUI's, such as NeWS, were available, but were scoffed at for some reason). More powerful interfaces have been around for years. I'll be among the first to check Berlin out (once it's in a usable state) for this very reason.
But hey, I'm a Mac and Linux user; I'd been spoiled by usable interfaces for years before switching to Linux. And if I do anything more I'll head off into a flamebait rant (which I honestly don't intend to do), so I'll shut up about it here.
Regardless, the article is for the most part just unprofessional FUD, and not something to be taken particularly seriously.