GLSL is still a fairly simple language, compared to something like c/c++, so writing a compiler should not be extremely difficult.
The big advantage of passing the high level code straight to the driver is that it allows for easier optimizations, simply because the conversion from high level -> assembly/bytecode inevitebly loses some of the context.
For instance (I don't know HLSL, but I have used Cg, which I'm told is almost identical to HLSL), the smoothstep() function provides a nice, smooth interpolation between two values. When I compile my Cg shader down to arb_vp (the assembly language), smoothstep has to be expanded to perform all the necessary arithemtic instructions sequentially, because there is no comparible instruction.
If the high level code were passed directly on to the driver, the driver could determine if for instance, this was a new piece of hardware that didn't exist when the game was made, and this hardware has dedicated smoothstep functionality, allowing the operation to be performed much faster than sequential instructions. The same information could be recovered from the bytecode, but it would be much more difficult.
The same general principle holds in other languages. Higher level doesn't necessarily mean slower or more difficult compilers. Look at Apple's extensions to C to allow easy utilization of the PowerPC's vector processor. A little hint from the programmer can make the job of writing an optimizing compiler much easier.
There are still serious bugs left from the previous revision, which was six months ago. That's a bit long to wait. While GLSL and 6800 support is nice, an interm bugfix wouldn't be unwelcome...
A problem that leaves the console framebuffer blank after X is started remains. You need to work around it by adding Option "IgnoreDisplayDevices" "TV" to your xorg.conf. If you are actually using TV out, this could be a bit annoying.
Even worse, it hasn't been more than 24 hours since I've installed them, and these drivers have already hung X twice. When an OpenGL process segfaulted, that process assumes state D (uninteruptable sleep), and becomes completely unkillable, along with X itself. I haven't figured out how to reboot cleanly once this happens. All I can do is ssh in, sync the disks, and hit the power button.
Well, I was wrong about that. I found the source again, and it's Watson that's been bought by an unnamed company... the last program that was made practically irrevelant by an OS X update.
http://www.karelia.com/watson/watsonFAQ.html
It's undoubtedly being rolled into Looking Glass or the Java Desktop System.
While it's nice that Karelia is finally getting some extra compensation for their work, Apple really needs to compensate shareware authors when their efforts copied into the operating system. Otherwise, there is little incentive to produce something new and innovative, because it will become irrevelant soon.
A couple days ago I saw a blurb about the rights to Konfabulator being purchased by an unknown company, and support/updates would be ceased sometime in August.
Unfortunatly, I can't remember what that source was now, and can't find it again.
From a linux user, I see backwards compatability as the biggest nightmare of linux today. There is just too much of it, and it's holding back progress. Many of the points I'm about to address come from OS X, as I'm also a happy user of that system, and think it's a model for what can be improved about operating systems if you're willing to sacrifice some backwards compatability.
Over 4 years ago slashdot was full of posts about how it would take the OOS community a couple weeks, months at most, to match Apple's nifty new compositing window system. Well, today 99% of us are still using X, and it really hasn't changed significantly. Even the extensions being worked on at FreeDesktop aren't in wide use, and it doesn't look like they will be soon.
We're still stuck with an ancient standard directory hierarcy, and multiple search paths meant to find the same thing (what? I still have to have a huge autoconf macro in order to find both the LDFLAGS and CFLAGS necessary to include library foo?). This obviously isn't the best it could be, and yet no one even considers trying to change, because 'that's the way it was always done'. Again, look towards OS X. Headers, libraries, resources, documentation, XML files with library metadata, everything associated with libfoo is contained in a single directory 'foo.framework', not scattered in/usr/include,/usr/lib,/usr/share. This conventional *nix approach practically requires a package manager to keep things straight. Then, all that is required to compile against it, both finding includes and library search path, is a simple '-framework foo' argument to gcc, which follows a single search path. Easier to write makefiles, without wasting your time in autoconf.
A lot of lessons have been learned since these systems have been designed. If you insist on supporting everything ever made, you're never going to get anywhere.
Java compilation speeds are probably in the same ballpark, but you want to be wary. In my experience, the Apple JVM has a very slow swing implementation, compared to win/linux, so you'll pay in runtime performance.
backend code (ie, no Swing), seems to fare a lot better.
And Xcode really isn't any good for Java development (and I have a lot of gripes with xcode even writing c/c++, so much so that I'm compiling KDevelop as I write this).
On OS X the 8500 and 9000 share the same driver: "ATIRadeon8500.kext".
I'm willing to bet that you saw the name of the driver loaded to support that card. Of course, as other responders to this post noted, the 8500 is actually a better card than the 9000, so this is still isn't great news for you:)
You don't need a "fully 64 bit OS" to get the speed improvements (although there still are memory limitations. see below). It would break a LOT of things, and really wouldn't be any improvement over the current offering. Unlike x86, PPC was designed for the 64bit transition from the start (even though it remained unused in Apple's product line for almost a decade), and so there is no speed penalty, whatsoever for running 32bit PPC code on a PPC970.
Specifically, the article states: So far Apple's machines can see all the memory, they can't yet do 64-bit calculations. Present it with a 64-bit calculation, and a Mac with a G5 chip still breaks it into two 32-bit pieces. That's because, Glaskowsky says, Apple doesn't have a 64-bit operating system
Among it's other inaccuracies, it claims that a 32bit machine can only address 2GB.
They fault Apple for only allowing 8 GB of RAM in a desktop enclosure, even though this is still a significant improvement. This limit is still physical, there are 8 slots, and the largest capacity chips are 1024MB right now. They will work when 2048MB chips are released, increasing the max capacity of the existing line to 16GB.
As for the 64bit calculation bit, that's also incorrect. If the binary is compiled for the g5, then 64bit calculations will not be split as they are on 32bit architectures. The downside is that this binary will no longer work on 32 bit machines, for the obvious reasons. For best performance/compatability, two binaries, one 32bit, one 64bit, can be compiled and placed in the same Application bundle, making the difference between the two irrelevant to the user (only a single icon to click on, works on both systems, full 64bit calculation on the g5)
The biggest limit of the G5s at the moment is (and it's quite severe), to my knowledge, a single processes can still only address 4gb, because the size of void* is still 4bytes. Apple will need to duplicate all the libraries in 64bit form to make this work seamlessly, which will probably have to wait until 10.4.
I know this is really nitpicking, and is somewhat offtopic (but there isn't a front page iTunes thread at the moment), but it probably needs to be said.
iTunes for Windows, just like Mac iTunes, does it's decoding using Quicktime. As crappy as you think Quicktime Player software is, the backend Quicktime library is very nice, especially in regards to it's modularity.
Any app that uses Quicktime Lib can now play AAC files (even the iTMS 'protected' ones), not just iTunes. Of course, not may Windows apps use quicktime, but the ability is still there.
Similarly, you can make Quicktime play OGG by installing a Quicktime OGG component (http://qtcomponents.sourceforge.net/). By extension, your shiny new Windows iTunes now plays OGG. Have fun:)
Apple's responce here is somewhat correct. For those who don't know, a quick background of Apple's DRM.
When you buy a song, that file is keyed to be played by a particular ITMS account. You can allow up to 3 computers to each play all songs keyed to account x. This is a system that is fairly easy and trouble-free for the normal consumer (one who just wants to listen, not resell). You only need internet access when origionally authorizing a machine, and never again thereafter, until you want to deauthorize to free up one of your 3 keys.
With this system, properly handling resold music is impossible. Apple would have to guarentee that the origional owner couldn't play the song any longer, and this just isn't possible within this framework. Once a computer has been authorized, Apple can't remove your ability to play a particular song (or all of them, for that matter), even if it wanted to.
Contrast this to almost every other approach (BuyMusic.com? I'm not sure, I can't read their website without a windows machine... lame) where if you stop paying, your songs stop playing.
It's a fundamental flaw in Apple's DRM design. To gain the kind of control they would need to allow resale, they would have to impose a DRM scheme that would, in general, be far more draconian, ie, something that used individual keys for each song (which would also be a nightmare to manage on the server-side).
Less then sensible? Maybe you just need a better air cooling design. Since the G5 was brought up in the post, it seems reasonable to mention that Apple is really pushing the idea that the G5's are quiet*:
If a system is having trouble dissipating that kind of heat with air flow alone (or sounding like a jet engine), then you just have a poorly designed system. And maybe it's just me, but I have some qualms about putting water in a poorly designed system.
* of course, we haven't had independent reviews yet, so...
Based on the listed specs from the manufactures, the new 30gig iPod is ~121k mm^3, while the Nomad is ~201k mm^3. Almost twice as large.
The Nomad is also 50% heavier.
And the kicker, the Nomad numbers are for the 20GB model, compared to the 30GB iPod. I couldn't find numbers for the 60GB version. I have no idea how the size and weight of the 60GB model compare to the 20GB model. Personally, I would bet larger over smaller.
For those that haven't held it, the old iPod was almost identical in size to a deck of playing cards, and the controls fell right under the thumb of the holding hand, so you could hold and control it completely with only one hand. And the new iPods are a lot thinner than the old ones.
The scroll wheel design is great. The sensitivty and accleration are perfect. I could scroll through 2000 songs in about 4 seconds, and still land on exactly the one you want without overshooting, with about 1 minute of practice.
I haven't seen any interface on the Nomad that will actually let you find your songs in such a huge library.
Re:Anyone seen real specs for Apple's format?
on
AAC vs. OGG vs. MP3
·
· Score: 4, Interesting
I'm wondering if there are any libraries out there for decoding them, even within the confines of the DRM...
While I'm not sure, I would say yes.
I noticed last night that the protected AAC files played both in the Finder's preview pane and in Quicktime 6.2 itself. I assume the actual AAC-Protected decoding is done in quicktime, and no modifications were made to the finder to allow it to explicitly play AAC-Protected files. This implies that any program that can use quicktime can also play protected AAC files.
I'd be suprised if may of the other mp3 players on the mac didn't already support playing via Quicktime, and by extension, playing AAC-Protected
Every bit of speculation I've seen focuses on why (not) Apple is going to buy Universal music.
But this doesn't have to be a black-and-white thing. There have been too many stores in mainstream media for this to be completely groundless (at least, I think so), and Apple can't afford to buy Universal outright, so I believe we should expect either a partial buyout (not even a controlling share), or/and perhaps Steve Jobs taking some significant management position within Universal Music, in addition to his Apple/Pixar duties.
There was that glimmer of hope, but I can't say I'm too suprised.
It's sunday, meaning it's "Microsoft is evil, and Apple is being good... for now" day. XML itself isn't the holy grail. Without proper documentation, it can be just as nasty to figure out as the binary Word file (depending on how competent the designers of the format were). But properly documented format, with schema, XML or not, can be a really nice thing.
And a wheel mouse is extremely nice. (Had to load osx drivers off m$ site to get it to work, yes osx drivers...) Not all features are supported or work right from app to app. Some standards would be nice. (Most programs are dumbed down to 1 mouse it seems also.)
Almost every app provides context menu support for commonly used commands, as well as wheel support (even though they don't ship 2button+wheel mice). Third buttons and beyond have no defined purpose, and are available for customization (which is what MS's mouse drivers do). The 2buttons+wheel should Just Work for every app for any USB mouse. I'm unsure about how the microsoft mice work, but if you needed drivers to get that basic functionality (and I would be suprised if you do), then that would be the fault of Microsoft rather than Apple, because that would imply their mouse doesn't conform to the defined USB mouse protocol.
Cut/paste/select all is annoying as hell, no standard like windows, or even KDE/Icewm/CDE.\
No standard for cut/paste/select all? Um, perhaps you should check the logo on that box and make sure it's a mac. It's cmd+c/cmd+x/cmd+v/cmd+a for copy/cut/paste/selectall, and it's been that way at least since I've been using macs (~1992). I can't recall using an app that didn't conform to these.
This is in contrast to the Linux box (running gome) I was using this afternoon and ran into no less than 3 different keyboard shortcuts for copy in various apps.
Cant even hit home/end to move the cursor on some apps command line.
home/end on the mac goes to the top or bottom of the file. To go to the begining or end of the line, cmd+left arrow or cmd+right arrow. About the only app I know of that doens't follow this is Terminal, which falls back to the unix standard of control-a and control-e
Alt-tab doesnt work, grabbed a 3rd party app to fix that.
You're right, it doesn't work. If you're pressing alt.
To switch between apps, you use cmd+tab. This brings every window of a particular app forward. Then, to switch between individual windows, cmd+~. It seems you would prefer to have to work your way through x many windows in one app before even getting to work your way through the next app's windows.
And to find software: versiontracker.com
How sure are they that this will work? The mac software market is very different from the PC software market.
While on Windows, the word most commonly associated with 'shareware' is 'crap', this is not the case on the mac. Due to the smaller marketshare, selling boxed copies of software on store shelves isn't a winning plan for anything but the largest players in the mac software biz. Because of this, a great deal of excellent software is released for mac.
Where on windows shareware has long since been given up as a dead end, the mac shareware market is alive and well, producing and supporting a large number of excellent programs. As a mac user, many of your staple programs would be shareware, not boxed commerical (this is one thing that really strikes a lot of 'switchers' as strange).
Just because they can make a good profit selling shareware on the mac doesn't mean it'll extend to windows. They'll probably do better actually selling boxes (bargin stuff, like what you'd find in the checkout line, not alongside the $50 large production games) rather than selling shareware in the windows market, simply because to windows users, a physical box implies that it's a real piece of software produced by a real company (a thought not common among mac users).
Did they go out of their way to look quicktime look bad?
Anyhow, your right, the Video codec used in the Quicktime file is Sorenson.... Sorenson. Not even Sorenson 3, but Sorenson 1! The difference is pretty much clicking a damned checkbox in the encoder!
Or even better, they could have used MPEG-4.
That's not the real kicker though... no, the Audio is even better. Take a wild guess what audio encoding they're using: None.
That's right, uncompressed audio. They had their coice of a dozen different audio encodings, including aac and vbr-mp3, and chose uncompressed audio. That's 14.3 megs of (POOR QUALITY!) audio for a 1 minute 25 second movie file.
Glad to know blizzard has a competent video group:)
STUPID - Eve Brecker, 15, of Montclair, N.J., is a fucking idiot. Although she chats to strange men late at night, she can't be bothered to remember to use spell check.
Of course she uses spell check, everyone does. Unfortunatly, we've filled our custom dictionaries with L33t Speak.
Re:Why is he reinventing the wheel?
on
Open Source TV
·
· Score: 1
Um, the whole point Apple is pushing mpeg4 is because they're no longer powerful enough to have their own proprietary standard win out.
You completely ignore the fact that if mpeg4 does become the de-facto standard for video content, then linux users won't NEED quicktime. Users on *any* platform could use their player of choice.
Quicktime is just the first widely used player to support both playback and encoding of ISO Mpeg4 files (in addition to mpeg4 video streams in other container formats, such as QT Movie files, which while becoming non-standard (even though the format is published), brings you a LOT of extra nifty features).
Now, as for using this weird java thing instead of Quicktime Streaming Server and a RTSP stream, I don't know.
Apple just announced their not going to update an old OS with hardware drivers for their new machines. They want to spend their development effort on the new OS. They are not going back and disabling features that already worked.
This will NOT take away your ability to boot OS 9 on existing hardware.
This will NOT take away your ability to run OS 7/8/9 apps on any hardware (including the new stuff) through classic.
About a month ago I thought about writing a shareware product that would do things like that (scroll area on the side of the pad). After a lot of research, I've concluded that it can't be done...
Unless a lot of secret Apple documentation suddenly falls into my lap... if you have such secret documentation, please don't hesitate to send it to me;)
A little background: The Trackpad on apple laptops (as well as the keyboard), are pseudo-ADB devices. Still. Even after ADB was supposted to be dead years ago. I say pseduo because Apple employees claim that the hardware really isn't ADB, but it acts like one as far as the OS is concerned (at the mouse/trackpad driver level. lower down, the situation may be different).
Because of this, from the level of the ADB Mouse Driver, it looks and behaves exactly like those old Apple Extended mice (except for a few additions, such as tap-click, drag, etc). The standard ADB Extended Mouse Protocol, (as documeneted in the Apple Technote 'Space Aliens Ate My Mouse'), only reports relative movements of the pointer, as a normal mouse would.
There is no mechanism for getting the absolute location of the users finger, rather than the relative movement. Without that, you can't remap part of the trackpad to be a scroll area.
Porn Stars? Apple beat you to it.
on
Switch Different
·
· Score: 1
Macworld New York Stream, starts 1 minute 10 seconds into the show.
Slashdot Mirror
GLSL is still a fairly simple language, compared to something like c/c++, so writing a compiler should not be extremely difficult.
The big advantage of passing the high level code straight to the driver is that it allows for easier optimizations, simply because the conversion from high level -> assembly/bytecode inevitebly loses some of the context.
For instance (I don't know HLSL, but I have used Cg, which I'm told is almost identical to HLSL), the smoothstep() function provides a nice, smooth interpolation between two values. When I compile my Cg shader down to arb_vp (the assembly language), smoothstep has to be expanded to perform all the necessary arithemtic instructions sequentially, because there is no comparible instruction.
If the high level code were passed directly on to the driver, the driver could determine if for instance, this was a new piece of hardware that didn't exist when the game was made, and this hardware has dedicated smoothstep functionality, allowing the operation to be performed much faster than sequential instructions. The same information could be recovered from the bytecode, but it would be much more difficult.
The same general principle holds in other languages. Higher level doesn't necessarily mean slower or more difficult compilers. Look at Apple's extensions to C to allow easy utilization of the PowerPC's vector processor. A little hint from the programmer can make the job of writing an optimizing compiler much easier.
There are still serious bugs left from the previous revision, which was six months ago. That's a bit long to wait. While GLSL and 6800 support is nice, an interm bugfix wouldn't be unwelcome...
A problem that leaves the console framebuffer blank after X is started remains. You need to work around it by adding
Option "IgnoreDisplayDevices" "TV"
to your xorg.conf. If you are actually using TV out, this could be a bit annoying.
Even worse, it hasn't been more than 24 hours since I've installed them, and these drivers have already hung X twice. When an OpenGL process segfaulted, that process assumes state D (uninteruptable sleep), and becomes completely unkillable, along with X itself. I haven't figured out how to reboot cleanly once this happens. All I can do is ssh in, sync the disks, and hit the power button.
iChat uses Jabber for local communication. Rendezvous is only used for finding other users on the local network.
Well, I was wrong about that. I found the source again, and it's Watson that's been bought by an unnamed company... the last program that was made practically irrevelant by an OS X update.
http://www.karelia.com/watson/watsonFAQ.html
It's undoubtedly being rolled into Looking Glass or the Java Desktop System.
While it's nice that Karelia is finally getting some extra compensation for their work, Apple really needs to compensate shareware authors when their efforts copied into the operating system. Otherwise, there is little incentive to produce something new and innovative, because it will become irrevelant soon.
A couple days ago I saw a blurb about the rights to Konfabulator being purchased by an unknown company, and support/updates would be ceased sometime in August.
Unfortunatly, I can't remember what that source was now, and can't find it again.
From a linux user, I see backwards compatability as the biggest nightmare of linux today. There is just too much of it, and it's holding back progress. Many of the points I'm about to address come from OS X, as I'm also a happy user of that system, and think it's a model for what can be improved about operating systems if you're willing to sacrifice some backwards compatability.
/usr/include, /usr/lib, /usr/share. This conventional *nix approach practically requires a package manager to keep things straight. Then, all that is required to compile against it, both finding includes and library search path, is a simple '-framework foo' argument to gcc, which follows a single search path. Easier to write makefiles, without wasting your time in autoconf.
Over 4 years ago slashdot was full of posts about how it would take the OOS community a couple weeks, months at most, to match Apple's nifty new compositing window system. Well, today 99% of us are still using X, and it really hasn't changed significantly. Even the extensions being worked on at FreeDesktop aren't in wide use, and it doesn't look like they will be soon.
We're still stuck with an ancient standard directory hierarcy, and multiple search paths meant to find the same thing (what? I still have to have a huge autoconf macro in order to find both the LDFLAGS and CFLAGS necessary to include library foo?). This obviously isn't the best it could be, and yet no one even considers trying to change, because 'that's the way it was always done'. Again, look towards OS X. Headers, libraries, resources, documentation, XML files with library metadata, everything associated with libfoo is contained in a single directory 'foo.framework', not scattered in
A lot of lessons have been learned since these systems have been designed. If you insist on supporting everything ever made, you're never going to get anywhere.
Java compilation speeds are probably in the same ballpark, but you want to be wary. In my experience, the Apple JVM has a very slow swing implementation, compared to win/linux, so you'll pay in runtime performance.
backend code (ie, no Swing), seems to fare a lot better.
And Xcode really isn't any good for Java development (and I have a lot of gripes with xcode even writing c/c++, so much so that I'm compiling KDevelop as I write this).
How did you 'bus scan' the output?
:)
On OS X the 8500 and 9000 share the same driver: "ATIRadeon8500.kext".
I'm willing to bet that you saw the name of the driver loaded to support that card. Of course, as other responders to this post noted, the 8500 is actually a better card than the 9000, so this is still isn't great news for you
You got the card advertised, not the better one.
You don't need a "fully 64 bit OS" to get the speed improvements (although there still are memory limitations. see below). It would break a LOT of things, and really wouldn't be any improvement over the current offering. Unlike x86, PPC was designed for the 64bit transition from the start (even though it remained unused in Apple's product line for almost a decade), and so there is no speed penalty, whatsoever for running 32bit PPC code on a PPC970.
Specifically, the article states:
So far Apple's machines can see all the memory, they can't yet do 64-bit calculations. Present it with a 64-bit calculation, and a Mac with a G5 chip still breaks it into two 32-bit pieces. That's because, Glaskowsky says, Apple doesn't have a 64-bit operating system
Among it's other inaccuracies, it claims that a 32bit machine can only address 2GB.
They fault Apple for only allowing 8 GB of RAM in a desktop enclosure, even though this is still a significant improvement. This limit is still physical, there are 8 slots, and the largest capacity chips are 1024MB right now. They will work when 2048MB chips are released, increasing the max capacity of the existing line to 16GB.
As for the 64bit calculation bit, that's also incorrect. If the binary is compiled for the g5, then 64bit calculations will not be split as they are on 32bit architectures. The downside is that this binary will no longer work on 32 bit machines, for the obvious reasons. For best performance/compatability, two binaries, one 32bit, one 64bit, can be compiled and placed in the same Application bundle, making the difference between the two irrelevant to the user (only a single icon to click on, works on both systems, full 64bit calculation on the g5)
The biggest limit of the G5s at the moment is (and it's quite severe), to my knowledge, a single processes can still only address 4gb, because the size of void* is still 4bytes. Apple will need to duplicate all the libraries in 64bit form to make this work seamlessly, which will probably have to wait until 10.4.I know this is really nitpicking, and is somewhat offtopic (but there isn't a front page iTunes thread at the moment), but it probably needs to be said.
:)
iTunes for Windows, just like Mac iTunes, does it's decoding using Quicktime. As crappy as you think Quicktime Player software is, the backend Quicktime library is very nice, especially in regards to it's modularity.
Any app that uses Quicktime Lib can now play AAC files (even the iTMS 'protected' ones), not just iTunes. Of course, not may Windows apps use quicktime, but the ability is still there.
Similarly, you can make Quicktime play OGG by installing a Quicktime OGG component (http://qtcomponents.sourceforge.net/). By extension, your shiny new Windows iTunes now plays OGG. Have fun
Apple's responce here is somewhat correct. For those who don't know, a quick background of Apple's DRM.
When you buy a song, that file is keyed to be played by a particular ITMS account. You can allow up to 3 computers to each play all songs keyed to account x. This is a system that is fairly easy and trouble-free for the normal consumer (one who just wants to listen, not resell). You only need internet access when origionally authorizing a machine, and never again thereafter, until you want to deauthorize to free up one of your 3 keys.
With this system, properly handling resold music is impossible. Apple would have to guarentee that the origional owner couldn't play the song any longer, and this just isn't possible within this framework. Once a computer has been authorized, Apple can't remove your ability to play a particular song (or all of them, for that matter), even if it wanted to.
Contrast this to almost every other approach (BuyMusic.com? I'm not sure, I can't read their website without a windows machine... lame) where if you stop paying, your songs stop playing.
It's a fundamental flaw in Apple's DRM design. To gain the kind of control they would need to allow resale, they would have to impose a DRM scheme that would, in general, be far more draconian, ie, something that used individual keys for each song (which would also be a nightmare to manage on the server-side).
Less then sensible? Maybe you just need a better air cooling design. Since the G5 was brought up in the post, it seems reasonable to mention that Apple is really pushing the idea that the G5's are quiet*:
http://www.apple.com/powermac/design.htmlIf a system is having trouble dissipating that kind of heat with air flow alone (or sounding like a jet engine), then you just have a poorly designed system. And maybe it's just me, but I have some qualms about putting water in a poorly designed system.
* of course, we haven't had independent reviews yet, so...
Based on the listed specs from the manufactures, the new 30gig iPod is ~121k mm^3, while the Nomad is ~201k mm^3. Almost twice as large.
The Nomad is also 50% heavier.
And the kicker, the Nomad numbers are for the 20GB model, compared to the 30GB iPod. I couldn't find numbers for the 60GB version. I have no idea how the size and weight of the 60GB model compare to the 20GB model. Personally, I would bet larger over smaller.
For those that haven't held it, the old iPod was almost identical in size to a deck of playing cards, and the controls fell right under the thumb of the holding hand, so you could hold and control it completely with only one hand. And the new iPods are a lot thinner than the old ones.
The scroll wheel design is great. The sensitivty and accleration are perfect. I could scroll through 2000 songs in about 4 seconds, and still land on exactly the one you want without overshooting, with about 1 minute of practice.
I haven't seen any interface on the Nomad that will actually let you find your songs in such a huge library.
While I'm not sure, I would say yes.
I noticed last night that the protected AAC files played both in the Finder's preview pane and in Quicktime 6.2 itself. I assume the actual AAC-Protected decoding is done in quicktime, and no modifications were made to the finder to allow it to explicitly play AAC-Protected files. This implies that any program that can use quicktime can also play protected AAC files.
I'd be suprised if may of the other mp3 players on the mac didn't already support playing via Quicktime, and by extension, playing AAC-Protected
Every bit of speculation I've seen focuses on why (not) Apple is going to buy Universal music.
But this doesn't have to be a black-and-white thing. There have been too many stores in mainstream media for this to be completely groundless (at least, I think so), and Apple can't afford to buy Universal outright, so I believe we should expect either a partial buyout (not even a controlling share), or/and perhaps Steve Jobs taking some significant management position within Universal Music, in addition to his Apple/Pixar duties.
There was that glimmer of hope, but I can't say I'm too suprised.
It's sunday, meaning it's "Microsoft is evil, and Apple is being good... for now" day. XML itself isn't the holy grail. Without proper documentation, it can be just as nasty to figure out as the binary Word file (depending on how competent the designers of the format were). But properly documented format, with schema, XML or not, can be a really nice thing.
And a wheel mouse is extremely nice. (Had to load osx drivers off m$ site to get it to work, yes osx drivers...) Not all features are supported or work right from app to app. Some standards would be nice. (Most programs are dumbed down to 1 mouse it seems also.)
Almost every app provides context menu support for commonly used commands, as well as wheel support (even though they don't ship 2button+wheel mice). Third buttons and beyond have no defined purpose, and are available for customization (which is what MS's mouse drivers do). The 2buttons+wheel should Just Work for every app for any USB mouse. I'm unsure about how the microsoft mice work, but if you needed drivers to get that basic functionality (and I would be suprised if you do), then that would be the fault of Microsoft rather than Apple, because that would imply their mouse doesn't conform to the defined USB mouse protocol.
Cut/paste/select all is annoying as hell, no standard like windows, or even KDE/Icewm/CDE.\
No standard for cut/paste/select all? Um, perhaps you should check the logo on that box and make sure it's a mac. It's cmd+c/cmd+x/cmd+v/cmd+a for copy/cut/paste/selectall, and it's been that way at least since I've been using macs (~1992). I can't recall using an app that didn't conform to these.
This is in contrast to the Linux box (running gome) I was using this afternoon and ran into no less than 3 different keyboard shortcuts for copy in various apps.
Cant even hit home/end to move the cursor on some apps command line.
home/end on the mac goes to the top or bottom of the file. To go to the begining or end of the line, cmd+left arrow or cmd+right arrow. About the only app I know of that doens't follow this is Terminal, which falls back to the unix standard of control-a and control-e
Alt-tab doesnt work, grabbed a 3rd party app to fix that.
You're right, it doesn't work. If you're pressing alt. To switch between apps, you use cmd+tab. This brings every window of a particular app forward. Then, to switch between individual windows, cmd+~. It seems you would prefer to have to work your way through x many windows in one app before even getting to work your way through the next app's windows. And to find software: versiontracker.comHow sure are they that this will work? The mac software market is very different from the PC software market.
While on Windows, the word most commonly associated with 'shareware' is 'crap', this is not the case on the mac. Due to the smaller marketshare, selling boxed copies of software on store shelves isn't a winning plan for anything but the largest players in the mac software biz. Because of this, a great deal of excellent software is released for mac.
Where on windows shareware has long since been given up as a dead end, the mac shareware market is alive and well, producing and supporting a large number of excellent programs. As a mac user, many of your staple programs would be shareware, not boxed commerical (this is one thing that really strikes a lot of 'switchers' as strange).
Just because they can make a good profit selling shareware on the mac doesn't mean it'll extend to windows. They'll probably do better actually selling boxes (bargin stuff, like what you'd find in the checkout line, not alongside the $50 large production games) rather than selling shareware in the windows market, simply because to windows users, a physical box implies that it's a real piece of software produced by a real company (a thought not common among mac users).
Did they go out of their way to look quicktime look bad?
:)
Anyhow, your right, the Video codec used in the Quicktime file is Sorenson.... Sorenson. Not even Sorenson 3, but Sorenson 1! The difference is pretty much clicking a damned checkbox in the encoder!
Or even better, they could have used MPEG-4.
That's not the real kicker though... no, the Audio is even better. Take a wild guess what audio encoding they're using: None.
That's right, uncompressed audio. They had their coice of a dozen different audio encodings, including aac and vbr-mp3, and chose uncompressed audio. That's 14.3 megs of (POOR QUALITY!) audio for a 1 minute 25 second movie file.
Glad to know blizzard has a competent video group
STUPID - Eve Brecker, 15, of Montclair, N.J., is a fucking idiot. Although she chats to strange men late at night, she can't be bothered to remember to use spell check.
Of course she uses spell check, everyone does. Unfortunatly, we've filled our custom dictionaries with L33t Speak.
Um, the whole point Apple is pushing mpeg4 is because they're no longer powerful enough to have their own proprietary standard win out.
You completely ignore the fact that if mpeg4 does become the de-facto standard for video content, then linux users won't NEED quicktime. Users on *any* platform could use their player of choice.
Quicktime is just the first widely used player to support both playback and encoding of ISO Mpeg4 files (in addition to mpeg4 video streams in other container formats, such as QT Movie files, which while becoming non-standard (even though the format is published), brings you a LOT of extra nifty features).
Now, as for using this weird java thing instead of Quicktime Streaming Server and a RTSP stream, I don't know.
Apple just announced their not going to update an old OS with hardware drivers for their new machines. They want to spend their development effort on the new OS. They are not going back and disabling features that already worked.
This will NOT take away your ability to boot OS 9 on existing hardware.
This will NOT take away your ability to run OS 7/8/9 apps on any hardware (including the new stuff) through classic.
I was wondering what this might be refering to. I guess this may be it.
About a month ago I thought about writing a shareware product that would do things like that (scroll area on the side of the pad). After a lot of research, I've concluded that it can't be done...
;)
Unless a lot of secret Apple documentation suddenly falls into my lap... if you have such secret documentation, please don't hesitate to send it to me
A little background:
The Trackpad on apple laptops (as well as the keyboard), are pseudo-ADB devices. Still. Even after ADB was supposted to be dead years ago.
I say pseduo because Apple employees claim that the hardware really isn't ADB, but it acts like one as far as the OS is concerned (at the mouse/trackpad driver level. lower down, the situation may be different).
Because of this, from the level of the ADB Mouse Driver, it looks and behaves exactly like those old Apple Extended mice (except for a few additions, such as tap-click, drag, etc). The standard ADB Extended Mouse Protocol, (as documeneted in the Apple Technote 'Space Aliens Ate My Mouse'), only reports relative movements of the pointer, as a normal mouse would.
There is no mechanism for getting the absolute location of the users finger, rather than the relative movement. Without that, you can't remap part of the trackpad to be a scroll area.
Macworld New York Stream, starts 1 minute 10 seconds into the show.
m wn y_mp4_2_28_56_100_300_ref.mov
http://stream.qtv.apple.com/events/jul/keynote/