Well, they'e not $300, but a Kihei iMac that's perfectly capable of runnin OS X and just about any average consumer application imaginable, can still be had for $800. That's a far cry from $3,000.
Well, the trend seems to be more self-contained devices that are simply improved by plugging them into a Mac. Especially with something like this, that would be more expensive, you'd want something that doesn't lose functionality when it's away from your desktop.
That said, I think the camera should remain separate from this device. Apple can't do digital video cameras as well or as cheaply as Canon, Nikon, etc., and they shouldn't want the extra support liability.
A consumer would want something they can take on vacation to their cottage in the mountains, plug in power, phone line, and camera and be ready to video-conference with their kids.
This could be a great aplication for something along the lines of the IBM Metapad.
Pondering the issue of what the person using it is supposed to use to receive video, I can only see two options(assuming the device isn't attached to a computer):
1. Integrated LCD. Would have to be small to be feasible without increasing product cost. 2. Use something just about everybody has... have a composite video out port on the device, allowing it to display incoming or outgoing video on a TV.
The more I think about this, the more it becomes basically an iBook with a small iPod-ish screen, and a greatly simplified key interface. Removing those things plus the trackpad would shrink an already small portable considerably - in size and price. You could go even smaller by eliminating the optical drive, but with that left in, such a device might be extended into the PVR arena. With video encoded as MPEG-4, you could fit quite a bit of TV onto a CD.
You make a fair point, but the ownership of the keying technology does not significantly change the probability of this outcome. It may even make more sense, since QuickTime is primarily an output platform - they might decide to do the keying in a hardware device (camera) with guts similar to an iPod.
Given the way Apple has approached things like digital cameras(still and otherwise), I'd consider one of the following more likely...
Apple creates an extension to iMovie that incorporates QuickTime broadcaster to some extent to allow for highly compressed MPEG-4 streaming to a specific destination or destinations. Sort of an iApp version of QuickTime Streaming Server.
Apple creates a small iDevice based on a low power chip which accepts Firewire(4 and 6 pin ports to accomodate different cameras without neding an extra adapter), and outputs through ethernet or phone line.
The device is automatically recognized(Rendevous at work) by any Mac if it's connected to a network, and can be configured either through a software interface, or browser. It also contains a simple keypad interface for dialing in phone numbers or IP addressed.
Highly portable, affordable video streaming/conferencing from anywhere that has even a phone connection. No (desktop/notebook)computer necessary.
Well, the G5 is still somewhere in the not "so distant future", but the G4 still has life. There are rumors that the next update will usher in DDR333, an a RapidIO bus designed by IBM and Motorola.
I have a feeling the Xserve was largely a way of whetting the appetite of Mac users, particularly professionals, for DDR and the performance boost it brings.
Rather than "Oh, hey, we;re throwing in DDR on all our systems. It's neat and stuff. Buy new computers please." We get "Here's the Xserve, and oh yeah it has DDR. Now, we're going to send these out to the press so they can spread the words of what a speed demon the machine is, but lament its high price compared to other Macs. Then, a little while later, we'll come along and say 'ok, now you can have the same thing in your desktop. Cheap.' And people will flock into the stores for them."
It's all about creating demand and giving people a reason to upgrade or replace systems that already work quite nicely. Because when people have something that works, sometimes just dangling a technological carrot doesn't work. You have to give them a taste of the carrot.
Well, I think we can safely assume that anyone doing serious computation in OS X is going to be looking at an Xserve from now on.
What the Xserve does is incorporate DDR RAM. Yeah, old news for the x86 side of things, but as explained in ars-technica's comparison of the P4 and G4e, the G4's primary problem is insufficient memory bandwidth. The processor is capable of more than what you're seeing even with a dual 1GHz. Additionally, optimizing software for Altivec can make a tremendous difference, and if Apple buys something out, you can pretty much be assured that they're going to tweak it in every way possible to get better performance.
In short, saying pro Macs are slower than Intel-based hardware is an over-simplification. Both processor families have advantages, and the G4's are largely untapped.
Of course, there's also the power-consumption and heat issue, which would become rather relevant in a large renderfarm.
They're actually using Apache. The server software is stable as a rock, but the server goes down every few weeks anyway.
And it was hardly a troll. It was an expression of frustration that their most tech-savvy employees didn't understand that PHP is using the same CGI standard that their old Perl system used.
Actually, as with Javascript, it's more like C++, right down to the $this.
It's also a language that makes even quick, simple, scripts tedious. For eveything PHP has built-in, and all the overhead it brings with it, you'd think it could make common stuff like string manipulation a bit easier.
And your analogy works too, on a different level. Yours addresses the ease and safety of getting somewhere, while the one I posted suggests that the Mac will do what you want it to.
And that big old engine can be useful for providing ballast to keep the car from rolling...
2. It doesn't crash
After spending years trying to fix Macs using conflict catcher, I hope they've finally got it right, but I'm not holding my breath.
In over a year of use, I've had one kernel panic. Considering that I am running this iMac with less RAM than the OS "requires", and not much free space for swap, I'd say that record is pretty darn good.
3. Simply the best in digital music
So, there's some Apple applications that don't run on PC's. Big deal.
Well, it's a pretty big deal to Windows drones when there's software that runs on Windows, but not on the Mac, so forgive us for bragging about it when the Mac has something Windows doesn't. It's made even sweeter because iTunes is a killer app.
It's not just an MP3 player. It's an incredibly sophisticated system for managing MP3 files that can be scattered all over a disk.
7. It's built for the Internet
I honestly don't understand this one. Most people can configure a PC for the internet in less than 15 minutes, so I notice they don't claim the Mac is easier (it's only implied).
It's far easier, because Mac OS X is based on standards, which means that in configuring a machine for an internet connection, there's no need to deal with all of the proprietary Windows hacks.
9. Works effertlessly with PCs.
This is not a plus over PCs, only the lack of a drawback.
It is an advantage. One that will be even better with 10.2. You see, the Mac is easier to integrate into a Windows network than a Windows machine.
If you don't want to have problems using audio files between the two machines, use MP3. If you wanted more files than 128 MP3 will allow for, don't buy a machine with only 128MB of memory.
Getting locked into Windows Media formats so you can stuff a few more songs onto an over-priced chintzy plastic Swiss Army knife of a digital appliance is a very poor decision.
Well, if you have an iBook that you're using to listen to music while on the road, you could always use this nifty new thing called iTunes that came for free with your iBook, and is fully functional as opposed to Microsoft's half-assed port of a player that plays non-standard files.
Even the older iBooks have plenty of space for several hours of good quality MP3s.
As a tangent, is this the case? Windows may have huge marketshare, but that's the sum of everything from Win 3.11 on up, and I know a LOT of people still running unpatched versions of Windows 95. So how large is the actual target market for.NET applications?
Compromise for the sake of interoperability is something that is done all the time. The question typically is whether the amount of compromise is worth the benefits of interoperability.
I think the real question here is not whether languages are limited to certain features in order to interoperate. This is a given, considering that so many languages offer functionality far beyond what C# brings to the table.
The real question is whether the CLR, which is ostensibly separate from the C# language, allows these languages to implement the things that make them worthwhile in the first place.
For instance, if I'm an Eiffel programmer, and I want to write a.NET program, can I use my favorite Eiffel features in addition to the.NET stuff, or do I get a bastardized language that's just going to drive me to C#?
If this is the case, then all that's happening is Microsoft playing the old "bait 'n switch" with developers.
You obviously didn't notice the Delvian with (blond)hair in the promotionals.
Re:Perl is Perl. Ruby is Ruby and Python is Python
on
Apocalypse 5 Released
·
· Score: 1
Probably simpler to look at it as:
Ruby is a pure object-oriented language. Everything is an object, everything that occurs is the result of a method of some class or instance method. Yes, it's similar to SmallTalk in that purity of concept, but pragmatically, it draws more from Eiffel, in my experience.
Python is an object-oriented language as well, but it also mixes in functional programming ideas. Methods are not exactly methods, but rather functions bound to a class or instance. That's what the "self" is about. Python automagically passes in that first argument, but you can "detach" the method from its class and call it like a function, providing self manually.
Python's weakness is the Huffman coding Larry talks about. As an example, regular expressions...
Ruby: reObj =/foo/i
Python: import re reObj = re.compile("foo", re.I)
And yes, I do like Python. There are things it does that I can't as easily do in Ruby. In particular, I like functions being treated as objects.
Slashdot Mirror
Well, they'e not $300, but a Kihei iMac that's perfectly capable of runnin OS X and just about any average consumer application imaginable, can still be had for $800. That's a far cry from $3,000.
Well, as long as you don't plan on ever having children in the future...
Speaking of G4 Powerbooks with DDR RAM, what's the melting point of titanium? ;-)
Well, the trend seems to be more self-contained devices that are simply improved by plugging them into a Mac. Especially with something like this, that would be more expensive, you'd want something that doesn't lose functionality when it's away from your desktop.
That said, I think the camera should remain separate from this device. Apple can't do digital video cameras as well or as cheaply as Canon, Nikon, etc., and they shouldn't want the extra support liability.
A consumer would want something they can take on vacation to their cottage in the mountains, plug in power, phone line, and camera and be ready to video-conference with their kids.
This could be a great aplication for something along the lines of the IBM Metapad.
Pondering the issue of what the person using it is supposed to use to receive video, I can only see two options(assuming the device isn't attached to a computer):
1. Integrated LCD. Would have to be small to be feasible without increasing product cost.
2. Use something just about everybody has... have a composite video out port on the device, allowing it to display incoming or outgoing video on a TV.
The more I think about this, the more it becomes basically an iBook with a small iPod-ish screen, and a greatly simplified key interface. Removing those things plus the trackpad would shrink an already small portable considerably - in size and price. You could go even smaller by eliminating the optical drive, but with that left in, such a device might be extended into the PVR arena. With video encoded as MPEG-4, you could fit quite a bit of TV onto a CD.
Given the way Apple has approached things like digital cameras(still and otherwise), I'd consider one of the following more likely...
Well, the G5 is still somewhere in the not "so distant future", but the G4 still has life. There are rumors that the next update will usher in DDR333, an a RapidIO bus designed by IBM and Motorola.
I have a feeling the Xserve was largely a way of whetting the appetite of Mac users, particularly professionals, for DDR and the performance boost it brings.
Rather than "Oh, hey, we;re throwing in DDR on all our systems. It's neat and stuff. Buy new computers please." We get "Here's the Xserve, and oh yeah it has DDR. Now, we're going to send these out to the press so they can spread the words of what a speed demon the machine is, but lament its high price compared to other Macs. Then, a little while later, we'll come along and say 'ok, now you can have the same thing in your desktop. Cheap.' And people will flock into the stores for them."
It's all about creating demand and giving people a reason to upgrade or replace systems that already work quite nicely. Because when people have something that works, sometimes just dangling a technological carrot doesn't work. You have to give them a taste of the carrot.
Well, I think we can safely assume that anyone doing serious computation in OS X is going to be looking at an Xserve from now on.
What the Xserve does is incorporate DDR RAM. Yeah, old news for the x86 side of things, but as explained in ars-technica's comparison of the P4 and G4e, the G4's primary problem is insufficient memory bandwidth. The processor is capable of more than what you're seeing even with a dual 1GHz. Additionally, optimizing software for Altivec can make a tremendous difference, and if Apple buys something out, you can pretty much be assured that they're going to tweak it in every way possible to get better performance.
In short, saying pro Macs are slower than Intel-based hardware is an over-simplification. Both processor families have advantages, and the G4's are largely untapped.
Of course, there's also the power-consumption and heat issue, which would become rather relevant in a large renderfarm.
They're actually using Apache. The server software is stable as a rock, but the server goes down every few weeks anyway.
And it was hardly a troll. It was an expression of frustration that their most tech-savvy employees didn't understand that PHP is using the same CGI standard that their old Perl system used.
Thank you!
A few days ago I asked a local site admin if their new system was using Perl or PHP...
"No, we're not using CGI anymore. We moved to PHP."
Of course, they do run everything off NT4 servers, so I really shouldn't have expected anything more.
Python does borrow some functional programming concepts. However, they're of a more Haskell-ish flavor. Things like list comprehensions.
Actually, as with Javascript, it's more like C++, right down to the $this.
It's also a language that makes even quick, simple, scripts tedious. For eveything PHP has built-in, and all the overhead it brings with it, you'd think it could make common stuff like string manipulation a bit easier.
Well, it was a hypothetical.... ;-)
And your analogy works too, on a different level. Yours addresses the ease and safety of getting somewhere, while the one I posted suggests that the Mac will do what you want it to.
And that big old engine can be useful for providing ballast to keep the car from rolling...
Apple already is wildly successful. Which is not to say they couldn't be even more successful.
Although the small increase in processing power may be far outweighed by the ease of use and stability of the Apple platform.
Disclaimer: borrowed from the AppleAddict forums.
If you're in Nevada, and you want to get to San Fransisco, do you:
I guess it comes down to this...
If you don't want to have problems using audio files between the two machines, use MP3. If you wanted more files than 128 MP3 will allow for, don't buy a machine with only 128MB of memory.
Getting locked into Windows Media formats so you can stuff a few more songs onto an over-priced chintzy plastic Swiss Army knife of a digital appliance is a very poor decision.
Well, if you have an iBook that you're using to listen to music while on the road, you could always use this nifty new thing called iTunes that came for free with your iBook, and is fully functional as opposed to Microsoft's half-assed port of a player that plays non-standard files.
Even the older iBooks have plenty of space for several hours of good quality MP3s.
That's unfortunate. "Eat Me" was one of the best hours of horror I've ever seen.
Heheheh. You honestly think the world is that simple?
It seems rather simple for an intelligent person to be against Microsoft, yes.
Must have been one of the few I missed.
Working late on Friday nights really sucks.
I think the word you're looking for instead is, "intelligent". It rolls off the tongue much more easily.
As a tangent, is this the case? Windows may have huge marketshare, but that's the sum of everything from Win 3.11 on up, and I know a LOT of people still running unpatched versions of Windows 95. So how large is the actual target market for .NET applications?
I think the real question here is not whether languages are limited to certain features in order to interoperate. This is a given, considering that so many languages offer functionality far beyond what C# brings to the table.
The real question is whether the CLR, which is ostensibly separate from the C# language, allows these languages to implement the things that make them worthwhile in the first place.
For instance, if I'm an Eiffel programmer, and I want to write a .NET program, can I use my favorite Eiffel features in addition to the .NET stuff, or do I get a bastardized language that's just going to drive me to C#?
If this is the case, then all that's happening is Microsoft playing the old "bait 'n switch" with developers.
You obviously didn't notice the Delvian with (blond)hair in the promotionals.
Probably simpler to look at it as:
/foo/i
Ruby is a pure object-oriented language. Everything is an object, everything that occurs is the result of a method of some class or instance method. Yes, it's similar to SmallTalk in that purity of concept, but pragmatically, it draws more from Eiffel, in my experience.
Python is an object-oriented language as well, but it also mixes in functional programming ideas. Methods are not exactly methods, but rather functions bound to a class or instance. That's what the "self" is about. Python automagically passes in that first argument, but you can "detach" the method from its class and call it like a function, providing self manually.
Python's weakness is the Huffman coding Larry talks about. As an example, regular expressions...
Ruby:
reObj =
Python:
import re
reObj = re.compile("foo", re.I)
And yes, I do like Python. There are things it does that I can't as easily do in Ruby. In particular, I like functions being treated as objects.