Slashdot Mirror
Jobs Previews Displays, Tiger at WWDC
DonaldGelman writes "Apple has just announced a 30-inch Studio Display capable of displaying a resolution of 2560x1600. The display requires a new Nvidia card with 2 parallel DVI connections. The display is going to retail for $3299 in August, and the Nvidia card for around $599." Jobs also announced new 20- and 23-inch displays, for $1299 and $1999 in July. All three feature a new aluminum enclosure, and DVI. Also from WWDC...
Jobs also previewed Tiger, with Spotlight (fast iTunes-like searching in all apps, and systemwide), Dashboard (Konfabulator-like widgets combined with Exposé for fast showing/hiding), Automator (visual AppleScript, combining prewritten actions into scripts), H.264 code for QuickTime (high definition scalable video from MPEG), iChat AV conferencing (up to 10 for audio, four for video), RSS reading in Safari, Core Image and Core Video (realtime filters at the core OS level), and system-wide Sync Services. All of this is extensible (except for iChat conferencing), with SDKs available for developers.
There's a lot here, and a more detailed description is forthcoming. Tiger will be available in the first half of 2005.
... it's Apple's WorldWide Developer Conference.
The Army reading list
For those of you wondering where the pictures on the cinema displays came from it's the Jungfrau Region of Switerland. The valley is the Lauterbrunnen Valley. Now if I could only get the display to go with the picture...
NMG
A nice Safari RSS screenshot, starring our favorite site.
Apple's basically gone and done their own version of the coolness that is Konfabulator, little widgets that do a variety of things.
Actually I think Apple are already on to this: See here
These new displays are:
1. Larger
2. Use DVI instead of ADC, so you don't have to have mac hardware to use them.
Not announced on stage, but previewed off, is 10.4 Server: includes 100% 64bit libs, ACLs, iChat server, SUS. Also includes NT migration tool, improved email, and a one-click SOHO setup. Nice bump.
--
$tar -xvf
"You can now host your own iChat server. Instant Messaging serves as a vital means of communication for organizations of all sizes, so it's useful to deploy and run your own private and secure IM server. Based on the open source Jabber project, the new iChat server in Tiger Server lets your company protect its internal communications by defining its own namespace, using SSL/TLS encryption to ensure privacy, and Kerboros for authorization. The iChat server works with both the iChat client in Mac OS X Tiger and popular open source clients available for Windows, Linux and even PDAs."
http://www.apple.com/server/macosx/tiger/
Remember Watson? Remember how Sherlock 3 basically became Watson?
Remember Konfabulator with all of its widgets? Well, now Tiger's going to have Dashboard. I wonder if it will accept Konfabulator widgets (which I've been using) or if there will be an "import" program? And Konfabulator 1.7 just added Expose-like features (press F8 to get your Widgets in front - useful).
Granted, Apple had something like this back in the older Mac days (or so I've read here and there), so it's kind of like they're "bringing back" something old into the new - but if you're an Apple developer, it seems as though there's always the fear that your favorite app will get assimilated into the next version of OS X.
Granted, I like OS X (my work is buying me a new Powerbook in about a week - yay me), but it does kind of make you go "Hm".
52 Weeks, 52 Religions with John Hummel
Hey we've being given an iSync SDK this year. You can't have everything! ;-)
"The performance gains and features supported by Core Image ultimately depend on the graphics card. Graphics cards capable of pixel-level programming deliver the best performance. But Core Image automatically scales as appropriate for systems with older graphics cards, for compatibility with any Tiger-compatible Mac."
Apple certainly doesn't seem cowed by Microsoft. There were three big banners at the WWDC dissing MS. One said "Redmond, start your photocopiers," One said "Introducing Longhorn" (above an image of a Tiger CD), and one "Redmond, we have a problem. Curiously, pictures are onPaul Thurrott's decidedly anti-Apple blog.
I really hate reading this panic "they're stealing!" attitude every time.
Let's do a review here, okay?"
Frankly, Konfabulator was a low hanging fruit. It didn't really introduce anything except using Javascript, it just tied together a batch of old technology with a very old Apple idea. It's common sense to realize that Apple would move widgets back onto the desktop and add Javascript support once they realized how well it would work out. About the only thing you can really take issue with is Apple's decision to use Javascript.
Just a nitpick...Apple bought SoundJam (and the team who wrote it), and turned it into iTunes.
banner pictures
It seems even the Konfabulator authors are surprised by this. Even as a mac fan, I think it is reprehensible.
I have been asking myself how long till Apple would put metadata to good use, and if it would be before WinFS and Reiser4. Well, it looks like the answer is here.
Please correct me if I got my facts wrong.
Not to be nit-picky, but Firewire doesn't really illustrate your point. Apple didn't adopt Firewire. Apple invented Firewire instead of using the standard (USB).
Different technologies. Apple needed to be able to do high-speed isochronous data transfer. Try taking input from a video camera over USB (especially USB 1.0, which was all there was when FireWire came out).
pooptruck
I think the i-line of products or e-line of products might be more what your looking for. Or you could just settle for something else.
The real reason they dropped ADC was that they realized there was a limit to how much power you could push through the video card, and the 23" display was right about at that limit. If you check Apple's tech specs, you'll see that the 30" display has a 150W power supply - it simply needs a separate cord and brick. And once you're resigned to having two cables, it makes little sense to nitpick about having three. I like how they've at least bundled them at the monitor end, though.
right-on rumor
I think you greatly underestimate its appeal. It's expensive, but huge screen real estate is worth it. I have the 23" display right now, and there's little doubt that I will eventually (within a year or so) get the 30".
Video editors and - especially - motion graphics designers use every pixel of those huge screens. And they have the bucks to buy them, too.
The Cinema Display started at $3,999 in its time and it was a bestselling product. This display is actually cheaper than the original!
D
Behold!
I live ze unknown. I love ze unknown. I am ze unknown.
They are using Dual-link DVI.
Go to the web page Apple.com
They are using a special NVIDIA card:
" The groundbreaking new NVIDIA GeForce 6800 Ultra delivers the industry's first 16-pipe superscalar architecture and support for the world's fastest DDR3 memory to raise the bar for 3D graphics performance. The specifications of the GeForce 6800 Ultra GPU, are stunning: Using over 220 million transistors it supports a 256-bit interface for an effective memory bandwidth of 35.2 GB per second which delivers 600 million vertices, 6.4 billion textured pixels per second. The GPU is built on an AGP 8X board and includes 256MB of DDR3 memory for use in the most demanding graphics applications. It is the first card available to support the DVI standard dual link digital signal specification from the two DVI ports it features . This capability is required to drive the new 30-inch LCD, high resolution Apple Cinema HD display. The combination of a GeForce 6800 Ultra with a dual processor Power Mac G5 driving two 30-inch Apple Cinema HD Displays is the definitive tool for the creative professional. "
It uses the DVI standard.
"Gentlemen, you can't fight in here! This is the war room." -President Muffley "Dr. Strangelove"
At least, that's not quite the way I read it, although there's obvious functionality overlap. It looks like Spotlight is taking advantage of the metadata search system in Tiger -- this sounds to me a lot like an implementation of BeOS's beautiful search functionality. (Panther is there in the speed, but BeOS allowed all that useful metadata searching that Panther's system doesn't -- Tiger's apparently does.)
No, a lot of those choices were made during the 80's, when no one else was doing anything like what Apple did, at least not to a significant enough degree to matter.
SCSI was adopted in 1985 for the Mac Plus. ATA was just being developed at about that time, and certainly was no standard (nor all that good).
The single mouse button was settled on sometime prior to mid-1981. The reasoning was basically that the three button mouse on the Xerox Alto had been confusing -- none of the buttons had any standard uses, apparently, and they were called the Red, Yellow, and Blue buttons, but the mouse had black buttons. A one button mouse simplified use and documentation.
As for multitasking, the Mac was never really designed to do that to begin with. So it was always something of a hack. That being said, most personal computers didn't multitask, or likewise had cooperative models, at the time these decisions were made.
You youngsters -- you don't realize that a lot of important things happened in the 70's and 80's that still strongly influence what we've got now.
-- This and all my posts are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
It's not all that standard, but there is a reason for it. Typographic points are 1/72 of an inch. To help with cracking into that market, Mac displays have traditionally had about that resolution.
It's a similar rationale for having the Amiga's clock rate as the NTSC clock.
Video editors and - especially - motion graphics designers use every pixel of those huge screens.
Absolutely. The 30" display is big enough to have a full-size HD window with plenty of round around it for UI stuff like your timeline.
On a 1920x1200 monitor, you either have to work in proxy view (ugh) or you have to live with a tiny strip of UI at the very bottom. The 30" screen fixes this.
I write in my journal
Content indexing has been in OS X from the start. There are several new twists with Tiger. First, the content index gets updated automatically in the background as files are changed and created, rather than just at scheduled indexing times (I think). But content indexing is only really useful for text files (and Word docs, PDFs, etc.). It's not much good for movies, or image files or whatever. So, in Tiger there is also a metadata indexing system. This system searches out metadata in a wide variety of file types and indexes it. So, for instance, EXIF data from your JPEGs and ID3 data from your MP3 files gets indexed. But searching at the level of entire files doesn't always make sense. For example, e-mail programs usually store many messages in a single file. So, Tiger also provides the ability to search specialized types of information, like e-mail or contacts or appointments, and have the results presented sensibly.
All of this is integrated into a single search interface. So, if you search for "cows" you'll get back all of your text-like documents containing information about cows, based on a full content keyword search, as well as all of your image files and MP3 files which have cows mentioned in their metadata, as well as all of your e-mail messages and appointments related to cows. And all of this happens in real-time, in a list that updates as you type your query. You can also save a query, and re-execute it at any time with a click. Basically, this is a bit like the iTunes "smart playlist" feature, but it's system-wide.
All of this collectively comprises the search technology that Apple is calling "Spotlight". This is a major new feature that many users are probably going to use dozens of times a day.
This space unintentionally left unblank.
As I understand it, resource forks are now a legacy feature of Mac OS 9. Cocoa applications store their resources in a special directory structure called an application bundle. Most data formats -- including compressed files, images, Adobe formats, Microsoft formats, PDF, and on and on -- haven't required the use of resource forks in years. Can't we finally retire this non-feature that was a clever idea if anybody else was going to support it, but a horrible impediment to cross-platform compatibility?
Breakfast served all day!
"Hacker "Sp33k" for leet, or elite. Originating from 31337 "eleet", the UDP port used by Dead Cow Cult, a hacker group, to access Windows 95 using Back Orifice, a notorious hacking program."
1 33 7
http://www.urbandictionary.com/define.php?term=
"B.) It's not for you Mr. Sixpack, it's for us artists. We plunk down $3000 -- $4000 once in a while for stuff like this."
Just wanted to apologize to everybody. That sounded elitist. I didn't mean for it to.
I'll add a lil more info here: The ability to see that many pixels on the screen is VERY important. Imagine trying to work at theater resolution (>2,000 pixels...) and only seeing a small chunk at a time, or seeing it downsized to where some of the detail is lost. That's problematic. Monitors that can run at >1,600 pixels are hard to come by. So if Apple is successful here, it'll drive prices down. Either we snag the Apple monitor, or the lower budget places get more bang for their buck.
That's why I was offended at the previous poster's comment. I wasn't trying to say "Im better than you", but rather "you're not the only person in the world". Sorry I didn't communicate that more clearly the first time.
"Derp de derp."
I wouldn't hold your breath. I've used intel's "auto vectorizing" compiler, and truth be told it doesn't auto vectorise shit. You need to write your loops in such a way that there's no way it can bail before the end of the loop, and ... I can't remember ... other stuff. Point is that I found it both easier and faster to use the built in MMX primitives (it was integer math) and go back to using gcc.
Altivec has another problem. The data structures *have* to be aligned on a 16 byte boundary. Note that this is not a "runs really slowly if it's misaligned" thing, this is a "comes to a complete screeching halt" thing. Moving between Altivec and scalar registers is also incredibly slow - it's necessary to write the data to memory then read it back in, meaning you need to move at least one cacheline in the process.
On the plus side, when you do get it right, Altivec f'kin screams along. You can do almost anything with it and be bandwidth limited on a G4. Dunno about a G5 - there are some _more_ limitations to using altivec on a G5 too.
Look into the gcc primitives, it's surprisingly easy.
Dave
I write a blog now, you should be afraid.
Intel CPU's do have this technology as well, although it's half the width (64-bits at a time, rather than 128-bit).
... it still kinda sucked).
The MMX registers are 64 bit, although they're not the main limitation of the MMX implementation. For some inane reason, Intel decided to use the floating point registers for integer data (namely, MMX registers) and so MMX doesn't require additional registers to be added. However, since you're absconding with the floating-point hardware, you can't do floating point math at the same time, and you have to save the state of the floating point hardware before you switch to MMX. In other words, MMX was... "interesting", but in the end, not that useful. After all, for one thing, it eliminated your floating point capability unless you wanted to context-switch out. (AMD's 'improvement' to that was 3DNow! which was basically "MMX that you can use for floating point as well!" - okay, better, but
AltiVec didn't have those limitations - it was very, very improved over MMX.
SSE, however, *did* add 8 new registers, and 128-bit wide objects, for floating point. So an x86 processor with SSE extensions does have 128-bit vector abilities, albeit in floating point. Vectorized integer math is a little rare (hence why MMX isn't that useful anyway) so AltiVec and SSE are actually pretty comparable. AltiVec does have 32 registers (which makes sense, of course, given PPC's 32 register scheme), whereas SSE only has 8 registers. I'm sure some comp. eng. person can come along and tell me why it's efficient to have vector hardware that's the same depth as your register hardware (as x86 has 8 registers and 8 SSE registers, and x86-64 has 16 SSE registers, and 16 normal registers)
(SSE2 basically said "OK, MMX really blew - now you can just use the SSE registers for integer as well.")
When Apple posts benchmarks showing their machines to be faster than x86 machines, the benchmarks almost always make heavy use of these SIMD instructions... and rightly so.
When Apple used to post benchmarks. A modern G5 can keep pace with top end Athlons and P4s anyday, without any specialized benchmarks. Be nice to Apple - the days of the "G3 is 50% faster than a Pentium II using Photoshop's 'G3K1ckZA$$' filter on a mostly-red image of a cow... on Tuesdays!" are over, thank God. And if you had vectorized code on the x86 (using SSE), the comparison wouldn't be that unequal, unless it was heavily biased towards the PPC's obvious strengths (high register count). Then again, it's not like the x86 has any real strengths anyway...
But anyway, my point was that the SIMD implementation on x86 isn't really very different than on the PPC, once you count SSE. SSE is register-starved compared to PPC, sure, but so is x86 in general. x86-64 removes that last limitation (mostly, 16 registers is still starved compared to 32, I guess) but I doubt there would be a big performance jump going from 16 128-bit registers to 32 128-bit registers. There's not a ton of code that could efficiently utilize that. There is *some*, sure, but not a lot.