The openmoko crew refuse to implement it cause there's no chip that comes with open driver as of today and there isn't any on the horizon.
What are Nokia using in the N800? Presumably that must have an open driver, otherwise Nokia would be violating the GPL by shipping the systems with the proprietary driver linked to their Linux kernel...
Personally, I think the Nokia N800 is a more useful portable browsing device than the iPhone, not least because you can run any software you want on it, and because of the better screen.
My last two T-Mobile phones were unlocked phones purchased elsewhere. I had no trouble getting T-Mobile to help me configure them for T-Zones Internet access and voicemail.
Well, the aliasing works for you, but notice that the line caps are still hopelessly wrong with the hardware anti-aliasing.
I don't have any brand new Macs to try the code on. Maybe I'll try it out at an Apple store, if they've fixed the drivers I might get interested in OpenGL development again...
Well, there's also the issue of how much of OpenGL is actually supported by the drivers you can get.
I don't know what it's like on the Windows side of things, but on the Mac even basic OpenGL stuff like smooth polygons and lines is totally broken. You have to resort to horrendous hacks involving textures just to get an antialiased line.
Yes, but just because they believe that it will damage someone's career doesn't mean that they themselves would damage someone's career because that person was a remote worker.
If someone asked me if I believed that being an atheist would make someone unelectable in the USA, I'd say yes, I believe that. Does that mean I would never elect an atheist? Not at all. I just believe that most other people are bigoted idiots.
It could be exactly the same principle at work in this case.
Over 60% of 1,320 global executives... said they believe that telecommuters are less likely to advance in their careers
So what? I bet over 60% of global executives believed there were WMDs in Iraq, that Saddam Hussein had something to do with 9/11, that ENRON was a great company, and so on. Just because global executives believe something doesn't mean there's any truth to it. Sheesh, what a non-story.
URLs are a subset of URIs. A URL defines a location where a resource can be accessed. A URI may merely be the name of a resource, i.e. a URN.
For example, globally unique IDs in Atom feeds are often URNs, and hence URIs; but URNs aren't URLs, and you shouldn't need or want to try to connect to something just because it's used as a globally unique identifier in an Atom feed and looks a bit like a URL.
This is relevant because many Internet specifications use URNs (or in the case of HTML, FPIs) as spec identifiers. For instance, XML namespace identifiers are URIs; and while some of them happen to be URLs too, the XML namespace recommendation says:
The namespace name, to serve its intended purpose, should have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists).
In the case of RSS 0.91, Netscape wrote the spec, and they used a URL and told people to connect to it to fetch the necessary information to parse the file. They could have used a URN, but I'm guessing they wanted to keep their options open as far as changing the spec on the fly.
(Of course, Dave Winer has a different approach to changing RSS specs on the fly...)
Most Linux users ARE truly ignorant when it comes to Windows.
Somehow I doubt that. I'm reminded of studies during the 90s that showed that Windows users typically had no knowledge of Mac OS, but Mac OS users typically had moderately detailed knowledge of Windows.
I suspect that the situation is similar for Linux. I would be very surprised if any significant percentage of Linux users had not:
Seen a Windows XP BSOD (or spontaneous reboot if you haven't turned off that option)
Experienced the joys of applying security updates and service packs and rebooting multiple times
I said that having an extensive library of specialist data structures is a good idea. What's a bad idea is not naming them clearly, and stuffing them all in the core API instead of in separate specialist libraries.
It's much better to have performance-oriented special purpose stuff in separate libraries, like BLAS or NAG. Keep the complexity of core Java down, make it more manageable for newcomers, reduce platform bloat, and so on. There's a reason why C has CBLAS, GMP and so on, rather than stuffing it all in libc.
If Sun had kept the core libraries down to size they might not have had to go rip it all out again to define J2ME. And it's not like they've done a good job of making J2SE include everything you need, either, stuffing in specialist data structures and leaving it to projects like Log4j and JUnit to implement things that would be much more useful to most people.
I still maintain that the keywords already implemented as part of HTML metadata are no more impractical than a reimplementation of the same thing but named "tags" would be.
If the original suggestion is that there ought to be a standard ontology for tags, then (a) it would have been nice if it could have been more clearly expressed, and (b) fat chance, even DCMI hasn't attempted that.
All the other structures I mentioned are part of the core Java platform, J2SE.
If the additional complexity was part of special purpose libraries for those who need all those choices, I wouldn't have an issue. Somewhere along the way the idea of Java being simple was lost.
BLAS is a library of common mathematical operations needed in sciences, 3D geometry and the like. It's designed so that the implementation can make use of vector hardware. For example, on the Mac, you can call Apple's CBLAS library and if the Mac has no vector processing (G3) you get a C implementation, otherwise you get the operation performed by the native hardware. Almost anyone doing serious number crunching in FORTRAN will be using BLAS or something similar, like the NAG libraries.
Yes, I was talking about array/Array/ArrayList/Vector, I hadn't even considered LinkedList. I'd be more inclined to believe it was cleverness rather than lack of foresight if they had compatible interfaces and the names actually reflected their properties (e.g. ThreadSafeArray or SynchronizedArray). And then there's generics...
Plenty of languages--including FORTRAN, which is the language this new one is intending to replace--make do with just the one array implementation. If you're going to be doing anything time-intensive you're almost certainly going to be using something like BLAS instead of the language-provided array objects anyway.
Search engines ignore the HEAD keywords because they were used by spammers. If search engines started paying attention to some standard for tags, spammers would fill their pages with tags, and search engines would go back to ignoring the tags again.
So there is no point creating a new standard for tags. It'd be redundant with the HEAD keywords standard we already have. Same features, same problems.
As for common formatting, I can just about see a case for a TAG or KEYWORD element in the next HTML spec, akin to KBD and CITE, so you could then specify formatting of tags in CSS.
Search engines that disregard keywords will disregard tags for exactly the same reasons.
And I see no purpose in trying to standardize the UI for humans to view and enter tags. That's as unrealistic as hoping to standardize the UI of site navigators.
Perhaps by benefiting from the lessons learned with Java, they mean they're going to plan ahead and have just the one implementation of each major data structure, rather than (for example) 4 different array implementations.
"Every time you move or resize a window on your Mac, Quartz uses the integrated OpenGL technology to convert each window into a texture, then sends it to the graphics card to render on screen."
Web applications aren't a good substitute for on-phone applications because they're much more expensive. Remember, this thing is tied to Cingular, who charge by the byte.
There are any number of phones that can do Google Maps, IMAP e-mail, take photos, play back MP3s, record movies, show a picture of someone when they call you, tell you the weather, browse the web, sync with your Mac, and so on. My tiny Sony Ericsson will do all that.
The iPhone is a phone like those, but with a somewhat better web browser, and a really pretty UI. On the minus side, it's large and locked down so you can't run your own applications. My current phone will at least let me put whatever Java MIDlets I want on it and has a free SDK I can run on my Mac.
Slashdot Mirror
Sounds to me like your pricing scheme is part of the problem.
What are Nokia using in the N800? Presumably that must have an open driver, otherwise Nokia would be violating the GPL by shipping the systems with the proprietary driver linked to their Linux kernel...
Personally, I think the Nokia N800 is a more useful portable browsing device than the iPhone, not least because you can run any software you want on it, and because of the better screen.
My last two T-Mobile phones were unlocked phones purchased elsewhere. I had no trouble getting T-Mobile to help me configure them for T-Zones Internet access and voicemail.
Well, the aliasing works for you, but notice that the line caps are still hopelessly wrong with the hardware anti-aliasing.
I don't have any brand new Macs to try the code on. Maybe I'll try it out at an Apple store, if they've fixed the drivers I might get interested in OpenGL development again...
The problems exist with both ATI and nVidia.
H WAA.html for some example screenshots.
See http://homepage.mac.com/arekkusu/bugs/invariance/
With this kind of brokenness in OpenGL, it's no surprise Apple decided to layer Quartz over the top.
Well, there's also the issue of how much of OpenGL is actually supported by the drivers you can get.
I don't know what it's like on the Windows side of things, but on the Mac even basic OpenGL stuff like smooth polygons and lines is totally broken. You have to resort to horrendous hacks involving textures just to get an antialiased line.
Yes, but just because they believe that it will damage someone's career doesn't mean that they themselves would damage someone's career because that person was a remote worker.
If someone asked me if I believed that being an atheist would make someone unelectable in the USA, I'd say yes, I believe that. Does that mean I would never elect an atheist? Not at all. I just believe that most other people are bigoted idiots.
It could be exactly the same principle at work in this case.
So what? I bet over 60% of global executives believed there were WMDs in Iraq, that Saddam Hussein had something to do with 9/11, that ENRON was a great company, and so on. Just because global executives believe something doesn't mean there's any truth to it. Sheesh, what a non-story.
For example, globally unique IDs in Atom feeds are often URNs, and hence URIs; but URNs aren't URLs, and you shouldn't need or want to try to connect to something just because it's used as a globally unique identifier in an Atom feed and looks a bit like a URL.
This is relevant because many Internet specifications use URNs (or in the case of HTML, FPIs) as spec identifiers. For instance, XML namespace identifiers are URIs; and while some of them happen to be URLs too, the XML namespace recommendation says:
In the case of RSS 0.91, Netscape wrote the spec, and they used a URL and told people to connect to it to fetch the necessary information to parse the file. They could have used a URN, but I'm guessing they wanted to keep their options open as far as changing the spec on the fly.
(Of course, Dave Winer has a different approach to changing RSS specs on the fly...)
Somehow I doubt that. I'm reminded of studies during the 90s that showed that Windows users typically had no knowledge of Mac OS, but Mac OS users typically had moderately detailed knowledge of Windows.
I suspect that the situation is similar for Linux. I would be very surprised if any significant percentage of Linux users had not:
...and so on.
You know, if you're gonna be a smartass on this topic, you should at least understand the difference between a URI and a URL.
There's nothing flawed about the notion of a permanent URI. A permanent URL is the tricky bit.
I said that having an extensive library of specialist data structures is a good idea. What's a bad idea is not naming them clearly, and stuffing them all in the core API instead of in separate specialist libraries.
It's much better to have performance-oriented special purpose stuff in separate libraries, like BLAS or NAG. Keep the complexity of core Java down, make it more manageable for newcomers, reduce platform bloat, and so on. There's a reason why C has CBLAS, GMP and so on, rather than stuffing it all in libc.
If Sun had kept the core libraries down to size they might not have had to go rip it all out again to define J2ME. And it's not like they've done a good job of making J2SE include everything you need, either, stuffing in specialist data structures and leaving it to projects like Log4j and JUnit to implement things that would be much more useful to most people.
I still maintain that the keywords already implemented as part of HTML metadata are no more impractical than a reimplementation of the same thing but named "tags" would be.
If the original suggestion is that there ought to be a standard ontology for tags, then (a) it would have been nice if it could have been more clearly expressed, and (b) fat chance, even DCMI hasn't attempted that.
All the other structures I mentioned are part of the core Java platform, J2SE.
If the additional complexity was part of special purpose libraries for those who need all those choices, I wouldn't have an issue. Somewhere along the way the idea of Java being simple was lost.
BLAS is a library of common mathematical operations needed in sciences, 3D geometry and the like. It's designed so that the implementation can make use of vector hardware. For example, on the Mac, you can call Apple's CBLAS library and if the Mac has no vector processing (G3) you get a C implementation, otherwise you get the operation performed by the native hardware. Almost anyone doing serious number crunching in FORTRAN will be using BLAS or something similar, like the NAG libraries.
Yes, I was talking about array/Array/ArrayList/Vector, I hadn't even considered LinkedList. I'd be more inclined to believe it was cleverness rather than lack of foresight if they had compatible interfaces and the names actually reflected their properties (e.g. ThreadSafeArray or SynchronizedArray). And then there's generics...
Plenty of languages--including FORTRAN, which is the language this new one is intending to replace--make do with just the one array implementation. If you're going to be doing anything time-intensive you're almost certainly going to be using something like BLAS instead of the language-provided array objects anyway.
Search engines ignore the HEAD keywords because they were used by spammers. If search engines started paying attention to some standard for tags, spammers would fill their pages with tags, and search engines would go back to ignoring the tags again.
So there is no point creating a new standard for tags. It'd be redundant with the HEAD keywords standard we already have. Same features, same problems.
As for common formatting, I can just about see a case for a TAG or KEYWORD element in the next HTML spec, akin to KBD and CITE, so you could then specify formatting of tags in CSS.
Search engines that disregard keywords will disregard tags for exactly the same reasons.
And I see no purpose in trying to standardize the UI for humans to view and enter tags. That's as unrealistic as hoping to standardize the UI of site navigators.
Perhaps by benefiting from the lessons learned with Java, they mean they're going to plan ahead and have just the one implementation of each major data structure, rather than (for example) 4 different array implementations.
This is Slashdot, people are more likely to remember Douglas Adams.
We've got a standard for keywords in HTML documents. There's no problem there.
The only issue is what to do when there are multiple sub-documents on a single page, like if Slashdot allowed individual replies to be tagged.
Yes you are. OS X 10.4 uses Quartz Extreme for window compositing on your Mac Pro, and Quartz Extreme is built on top of OpenGL:
Web applications aren't a good substitute for on-phone applications because they're much more expensive. Remember, this thing is tied to Cingular, who charge by the byte.
There are any number of phones that can do Google Maps, IMAP e-mail, take photos, play back MP3s, record movies, show a picture of someone when they call you, tell you the weather, browse the web, sync with your Mac, and so on. My tiny Sony Ericsson will do all that.
The iPhone is a phone like those, but with a somewhat better web browser, and a really pretty UI. On the minus side, it's large and locked down so you can't run your own applications. My current phone will at least let me put whatever Java MIDlets I want on it and has a free SDK I can run on my Mac.