At least maybe we'll no get ecash. If the physical stuff is traceable the primary disadvantage of the elctronic stuff is gone. Not that I have anything to hide;)
And yes, that's a pretty poor silver lining.
I wonder if they'll declare the currency worthless if you were to tear out the chip (or otherwise fry it - how possible is that?)
Firstly, the BBC is not a business. Its a non profit (well, actually, its 2 companies, one of which is non profit, one of which is for profit. I wonder which pays for internet streaming...?)
Secondly, I doubt they offer technical support on their current Real streams anyway. They're a traditional to air broadcaster, ultimately they don't get any revenue off of Internet streaming anyway. I'm not even clear *why* they do it at all (but I'm damn glad they do).
Thirdly, I seem to recall having to install real player...
Fourthly, this is Mac OS where I'm sitting, so I'm not exactly getting Windows Media player installed out of the box either.
Batch/Shell script - sucky on any platform, especially bad on Mac OS.
Double clickable jars - better on any platform, but most end users won't know how to use them, so a file like "How do I launch this fscking app?" would probably need to be in the distro.
As for MRJAppbuilder - its the only option (other than CodeWarrior or the ProjectBuilder IDE) that will give you that polished application. You might investigate if CodeWarrior on Linux or Windows can make Mac Java apps, but I'd guess not, and it obviously costs money.
As for MRJ app builder, its written in Java, but it might well need native code. You could certainly write the xml files required, but it uses a small binary launcher stub.
Then again, since you obviously care about user experience you should really be producing a little.exe launcher on Windows... which would be just as difficult if you develop on Unix or Mac OS.
You might be able to build a generic launcher that will launch any java application which follows some naming convention you define (eg, make your jar be called appClasser.jar and your main class be com.myclasses.Main). Certainly this was possible on Mac OS 9 - then you wouldn't need to regenerate the launcher every time you release.
File a bug with Apple requesting a cross platform solution (developer.apple.com). You need to join up, but its free.
As for opening IE - if all you do on Windows is
Runtime.exec("iexplore.exe");
then you've just annoyed me, because you've ignored my browser preferences.
What you want is Eric Albert's BrowserLauncher... works out the user's prefered browser and works pretty much everywhere you're likely to want to be, and is free:
My apologies, I'm just a little sick of explaining the same thing over and over again.
Actually, the Quicktime container format forms the basis for the MPEG-4 standard (which is itself a container format).
MPEG-4 also suffers from confusion between "MPEG-4 the container format spec" and MPEG-4 the video compression codecs currently being used. Of course, the companies like to call it just MPEG-4 because it makes it sound better than MPEG, MPEG-2 and MP3.
Both Quicktime and WMF are moving towards or already do support MPEG-4. So perhaps one day each codec can be packaged only one and used with any MPEG-4 compatible container format.
Assuming Apple and Microsoft don't "improve" on the standard, of course.
Oh dear, another ignorant soul who doesn't know the difference between the container format (Quicktime) and a codec (Sorenson).
Quicktime is just a wrapper around any codec you want to use. Currently that tends to be Sorenson 3 as its the best one shipped. I also watch various Divx movies that are in Quicktime format, since I installed the plugin that lets me do that.
Since he says it works on Mac OS, the chances are he already has a Quicktime plugin for his codec. Infact, he'd be insane *not* to package it in one of the major container formats as these have "install on demand" support.
User goes to a page with a movie in their wizzy new codec, and, if he can get the deal set up, Quicktime just says "you don't have the codec you need to see this movie click ok to download and install now?".
> What feature of Objective C makes templates unnecessary?
Confession time - I saw something that I was pretty sure would solve this when I was halfway through the objective C book, but I don't recall it off the top of my head. I posted a link to the book elsewhere on this page...
> It's somewhere in between C++ and Java in
> terms of cleanliness of the langauge
Certainly the syntax has some clunkiness here and there (how you define private methods springs to mind). I think overall I might be prepared to trade these inconveniences for much later binding than Java though...
>When I got mac OS 10.1, one of the docs
>said something about Objective C++,
>which sounds scary as hell...
Actually, I think all that is is a way to call libraries written in C++ from Objective C (and maybe vice-versa?). Not scary, actually pretty useful (be a bit annoying if all you could link to was other objective c libs or C but no C++ libs)
>That's why I think we need to shift some
>of the burden from class libraries to languages
I'm inclined to agree with you. Its nice to see "assert" becoming a keyword in Java rather than a library based kludge. And where would we be without try/catch/finally semantics.
Java Reflection is an example I have mixed feelings about. Its done (almost) entirely through classes, and it sure does feel clunky sometimes. But it landed in Java 1.1 without causing many problems (because it didn't change the language...)
Inner classes are an interesting one too. They did change the language, but not the runtime, because they were able to fake it in the compiler (actually, this is true for Java generics too, you have to use a special compiler, but it runs on straightup JDK 1.3/1.2).
Of course it depends on who you are and what you want, but for most people most of the time, the libraries is where the action is at.
Technically, you're right, of course. You don't *need* stdclib, you don't need javax.* or STL. Its just that most of the time you'd want to use these things, unless your needs are specialised. [*]
Things like gjc are niche applications. Technically, you're right, you don't need the Java or.NET Runtime. In practice almost everyone uses or will use it. It doesn't mean I wouldn't like to see more ppl using gcj, but currently its niche.
The reason people use it is because they perceive it will allow them to develop more complex applications more quickly (and hopefully more secure, and more robust etc). And that's what's relevant when comparing class libraries.
To some extent I'll shut my mouth over MFC, for indeed there I don't know how much more useful it is or isn't. In this context it doesn't really matter whether its a good library or not though. My point was that its a waste of time to compare languages if you should be comparing libraries. If you compare MFC and find its unnecessary, that's a valid thing to do...
[*] I'll give you that I should have been more specific. eg, a client side Java programmer probably doesn't need javax.*, but a server side programmer almost certainly will at some point. Sure, they could code it all from first principles, or java.* classes, but most people will never need to. So no, its not essential, its just "extremely useful". If one's splitting hairs, then yes, that's not the same thing.
If you want to know more about objective c, or to prepare before reading the books above, or to gain more depth of understanding of the language if the chapter or so spent in the above books doesn't explain enough, then look no further than this:
There are tons of posts here saying Objective C has an ugly syntax.
What they mean is it doesn't look like C and C++ and Java.
Of course, how it looks has no bearing on how useful a language it is (heh, think Perl;), but these people are too ignorant or blinkered to realise this.
Who cares what the syntax for calling a function is? So long as its not 3 pages of code its irrelevant.
Do we see any insightful comparison of the truly powerful language features from these people? Do we see discussions of how C, C#, C++, Java and Obvjective-C's approach to types and bindings work? How they support dynamic behaviour?
eg, I'm prepared to state that Objective-C makes generic types unnecessary, whereas C++ relies on them and Java is introducing them (slated for JDK 1.5). This is a good thing in C++, will be a good thing in Java, and I expect to see them in C# one day, because of commonality between how these languages are defined. Objective-C doesn't need them, it has another solution, more akin to Smalltalk.
We don't see this sort of comment (shallow though my example is) from most of the posters here because frankly all that they're experienced enough to comment on _is_ the syntax.
Even all that said - the features of the language pale into insignificance next to the quality of the class library. Java is nothing without the java.* and javax.* classes, C# is useless without the.NET runtime or at least the Base Class Libraries. C is limited without sdtlib, C++ needs the STL or on MS platforms (shudder) MFC to get the full benefits.
This is a review of a book about Cocoa, not Objective-C. The class library, not the language. The class library will dominate any concern over the language used to program it. Learning a language takes days (or weeks if its something completely new to you like your first declarative functional or logical language). Learning a class library can take months or years (depending on the size).
Do yourself a favour and learn some more languages. Learn about languages. Use real class libraries. Then open your big mouth!
In the UK, Sinclair computers and their derivtives were huge - much more well known than the US Timex TRS-XX machines (though geeks here seem to remember them fondly:
IIRC, all these machines had some Z-80 derivative:
ZX80 1K RAM (actually named after the year it came out)
ZX81 1K or 16K RAM
Spectrum (development codename ZX82) 16K or 48K RAM [+]
Spectrum + (larger, "better" keyboard)
Spectrum 128 (a vast 128K of RAM)
Spectrum 128 +2 (built in cassette deck!)
Spectrum 128 +3 (build in 3" *not 3.25"* 2 sided (by ejecting it and turning it over) floppy disk)
There were a couple of others.
Then also things like the
MGT Sam Coupe - which was compatible
I, my family or my firends owned every single one of these fine Z80 powered machines at one time or another. Hell, I learned to program in Sinclair basic. If Zilog have gone under (Chapter 11 doesn't mean its necessarily over) this is a sad day.
[+] actually this was a marketing lie. It had 32K RAM and 16K ROM with a unified address space. I think the 16K version had the same ROM, so it would be fairer to call that a 32K, if you want to include the total...
heh. Actually, I think I did the HTML version first then did Word. They want to print it, you see and lets face it, that's not HTML's strong point.
I work for a consultancy, which means my resume may go to the client also, and they're often banks, so it has too look good or it reflects badly on my employer. So Word/PDF end of discussion.
Maybe in 20 years...
Re:E-mail will not kill the fax machine
on
Email Turns Thirty
·
· Score: 1
Having just found a new job, I can say not a single employer I saw was not accepting email and/or web applications.
Of course, this is New York, it was an IT job and I saw all of the adds online. I'm sure your mileage will vary in other locations and industries.
And yes, they all wanted Word or PDF and they all printed them out for the interview, but its not exactly hard to print a file that's been emailled to you! This is more about people wanting hardcopy than anything else. I don't think most peoeple care whether that hardcopy is faxed to them or they have to print it out.
Its a plugin technology - clearly the Quicktime player could be ported if there were *no* plugins available for any codec... it doesn't require Sorenson to operate. Hell, you can still open Cinepack Quicktime version 1 movies fine, last time I checked.
And similarly Sorenson could (if so inclined and able under their license agreements) make a plugin and test it using the OpenQuicktime or Quicktime 4 Linux stuff...
Incidentally, I remember when we first got Quicktime, on a floppy from Apple. System 7 days. 25 MHZ 680X0 processors 2-5 MB of Ram. 12" 256 colour screens & 9" monochrome. And there was Video! It was the size of a postage stamp, but it worked. Amazing...
You know - back then they didn't market it as a video technology? (though everyone knew it was). If I recall the original readme correctly, it talked about agnostic support for multiple simultaneous data streams, but they gave examples like "logging several scientific instruments together", not like "playing video and audio at the same time". LoL...
>PS2. 90% of the posts can be answered with this: >"complain with Sorenson to port the codec to Linux".
Unfortunately I think Apple require Sorenson to exclusively license their products to only Apple, at least as far as the decoders go. Otherwise I guess we might see Sorenson support in Windows Media Player or Real.
I know this was true for earlier Sorenson, can't see it having changed for 3.
As pointed out ad nauseum by people on the last story, QUICKTIME IS A CONTAINER FORMAT. It WRAPS different streams of audio and video.
The supported audio formats include WAV, AIFF, AU, mp3 and half a dozen others.
The video standards used have included CinePack, 3 different versions of Sorenson and even Intel's Indeo video (used for years in Microsoft AVIs).
The container format is supported on Linux
Open Quicktime
The problem is Sorenson is exclusively licensed to Apple and they do not release it for Unix/Linux.
The other layer of ignorance is that MPEG-4 is also a container method for compressed audio and video streams. In fact its very similar to Quicktime (the packaging standard) indeed because it is actually _based on_ Quicktime!
That's not going to help Linux if they keep using Sorenson. It might help Mac users watch 3ivx, Divx and whatever other encoding formats are sometimes refered to as MPEG-4. You're not going to find this out from the CNET article though. Actually, since Quicktime is a container format, it supports pluggable codecs, so I watch MPEG4/{X}ivx video in Quicktime already - but it sure would be nice if Apple shipped those codecs out of the box.
The article is BS on many other points in any case - I would estimate over 50% of the streaming video I see out there is available in Quicktime format (though often alongside one of the other two). I mean, its very much the right tool for the right job at present... have you ever seen a good looking movie trailer in Real Video? I've seen a couple of OK ones, but the filesizes were similar to better looking Quicktime packaged (ie, Sorenson encoded) trailers. On the other hand I might use Real where image quality is less important. Oh, and of course, Quicktime includes mp3 support - its not competing with it!
So what does all this mean? Obviously Apple adopting MPEG4 could mean one of two things:
Since the MPEG 4 packaging standard is based on QuickTime, perhaps they are just updating it so the next Quicktime is 100% compatible with the official standard. This would certainly help the Open Quicktime people, as they can then just write to the MPEG-4 standard
It may mean Apple are going to ship the codecs commonly used with MPEG-4 (ie, the {X}ivx variants, FivX, 3ivx etc). That would help Linux because it would mean more Quicktime movies would exist compressed in formats which are available on Linux.
If Apple stick with pushing Sorenson as the primary codex (and hey, it is *really* nice looking) and don't ship any of the typical MPEG4 codecs, well that's not much news. If they ship {X}ivx alongside Sorenson, that's great because it allows content producers to choose, and Linux users can ask them to choose the more widely available {X}ivx compressors.
If I was more naive I'd say I can't believe CNET were presenting the "move" to MPEG4 as a retreat for Quicktime. MPEG 4 is the standardization of Quicktime and a vindication of its owenership of the professional market! Are they stupid or deliberately spinning it - you decide!
So all in all the CNET article is biased, tells you very little about what's actually been announced (is it new codecs? is it more standards compliance?) and tries to spin a victory as a defeat. Oh yeah, and Timothy's comments show he has no clue in this area either...
iirc the perceived problem is that the sample size is only 16 bits on regular CDs (some formats, like minidisc and sacd have larger sample sizes) so fine differences may get aliased to the same value.
These things have several related variables:
sample rate (44.1khz for cd)
sample size - (16 bit for cd) which determines
range of representable values
minimum difference between any 2 consecutive samples
I think its the later where CD sails close to (many say well inside of) what's perceptable by humans, and this is one of the things the newer formats try to address.
They're not intended to replace JPEG[*] they're best suited for application where you would use a GIF. As with GIF the compression is lossless and best for compressing line art and simple computer generated stuff.
In addition to GIF you also get:
* > 256 colours
* Full 8 bit alpha channel (but not in IE on Windows:(
Then there's MNG - for animated PNGs like animated GIFs and [*] JNG which in a PNG which internally uses uses JPEG compression and thus is pretty good with photos. These are more obscure though. I think JNG might allow transparency/alpha channel, which would be cool, as regular JPEG does not.
2/ allows me to type 4 chars more than it actually accepts in the field, thus helpfully truncating whatever I can fit in the subject?
Newcastle & London: only a few hundred miles a
on
Inventions of 2001
·
· Score: 0, Redundant
I know its only a few hundred miles, but you'd think anyone who acutally bothered to read the article would realize a bridge over the Thames in London that swayed a bit and one over the Tyne in Newcastle are in two completely different places?
I think this guy's a few chips short of a full butty myself...
Can you tell the difference: Newcastle & Londo
on
Inventions of 2001
·
· Score: 1
I know its only a few hundred miles, but you'd think anyone who acutally bothered to read the article would realize a bridge over the Thames in London that swayed a bit and one over the Tyne in Newcastle are in two completely different places?
I think this guy's a few chips short of a full butty myself...
That's right, genius boy. You need to hire more people and buy additional hardware to open a port or to download a few song titles. Not. Wakeup call - we had a flat rate T1. They didn't care if we ran high bandwidth stuff like streaming audio - and we could, because real audio tunnels on port 80.
Anyway, its called "an example".
As in, an example of how stupid it is that people can stream audio or use dangerous RPC like services or whatever, so long as its port 80, but something *completely innocuous* and *low bandwidth* is blocked purely because its on a different port.
Both you, and that company, need hitting with a cluestick...
Heh, well I knew an admin at a 30 year old company (no.domb this one) who setup an mp3 jukebox with html interface for streaming to the whole office. YMMV:)
Besides, I can actually listen to music and work at the same time you know...
Here's the other thing that drives me crazy about this:
The overhead of all of the layers required to do RPC over HTTP (yes, I know it doesn't have to be HTTP, but that's what we're discussing here) is huge compared to the performance on raw sockets.
Secondly, the protocols in question are brand new. As are all the implementations. They haven't been audited, field tested or generally kicked around enough. Certainly not as much as the 30 year old ones, or even HTTP - and HTTP is very very simple - these are full function calling systems!
Sure, there's probably some benefit in that the modern protocols were designed with security in mind, and the older ones usually didn't consider it, but that won't protect us from design flaws or implementation bugs that there hasn't been time for the community to find.
So all in all I think all we did was bow to ignorance and introduce a lot of redundant overhead which is *less* proven secure than the older stuff.
Its funny, its so obviously the classic tradeoff between security and convenience. It seems people want these services, but they were insecure. So now they're still wanted, but just tunnelled through something to give everyone a *very probably false* sense of security.
Every large organization I've worked for is like that. They *will not* open new ports, but most of them pay no attention to what's going on on 80, 25 and the few other ports they do allow.
Its hardly surprising: they've all been sold on the all they need is a firewall. Then when they discover they need a policy for that firewall and for handling requests from their staff, they all choose to do "whatever everyone else does". This means HTTP, SMTP and POP bascially. (I'll refrain from commenting on how "secure" those three are.)
I was once told (at a previous job) I couldn't have CDDB because it was MP3-ish and might be used by music pirates. (In case you don't know, its a service for looking up the titles of songs, not getting the music itself. I explained this to the guy. He said "I know" but its still not happening.)
Actually the other thing that goes on is people outsource their firewall management. Every time you call you wait a week to get the person who knows their account, then they charge $$$ per hour to make a change. I think we found the real cause of my "no-CDDB" problem.
Slashdot Mirror
At least maybe we'll no get ecash. If the physical stuff is traceable the primary disadvantage of the elctronic stuff is gone. Not that I have anything to hide ;)
And yes, that's a pretty poor silver lining.
I wonder if they'll declare the currency worthless if you were to tear out the chip (or otherwise fry it - how possible is that?)
Firstly, the BBC is not a business. Its a non profit (well, actually, its 2 companies, one of which is non profit, one of which is for profit. I wonder which pays for internet streaming...?)
Secondly, I doubt they offer technical support on their current Real streams anyway. They're a traditional to air broadcaster, ultimately they don't get any revenue off of Internet streaming anyway. I'm not even clear *why* they do it at all (but I'm damn glad they do).
Thirdly, I seem to recall having to install real player...
Fourthly, this is Mac OS where I'm sitting, so I'm not exactly getting Windows Media player installed out of the box either.
Oh, I see your point, but you overstate the case.
Well, your options would be threefold...
.exe launcher on Windows ... which would be just as difficult if you develop on Unix or Mac OS.
Batch/Shell script - sucky on any platform, especially bad on Mac OS.
Double clickable jars - better on any platform, but most end users won't know how to use them, so a file like "How do I launch this fscking app?" would probably need to be in the distro.
As for MRJAppbuilder - its the only option (other than CodeWarrior or the ProjectBuilder IDE) that will give you that polished application. You might investigate if CodeWarrior on Linux or Windows can make Mac Java apps, but I'd guess not, and it obviously costs money.
As for MRJ app builder, its written in Java, but it might well need native code. You could certainly write the xml files required, but it uses a small binary launcher stub.
Then again, since you obviously care about user experience you should really be producing a little
You might be able to build a generic launcher that will launch any java application which follows some naming convention you define (eg, make your jar be called appClasser.jar and your main class be com.myclasses.Main). Certainly this was possible on Mac OS 9 - then you wouldn't need to regenerate the launcher every time you release.
File a bug with Apple requesting a cross platform solution (developer.apple.com). You need to join up, but its free.
As for opening IE - if all you do on Windows is
Runtime.exec("iexplore.exe");
then you've just annoyed me, because you've ignored my browser preferences.
What you want is Eric Albert's BrowserLauncher... works out the user's prefered browser and works pretty much everywhere you're likely to want to be, and is free:
http://browserlauncher.sourceforge.net/
My apologies, I'm just a little sick of explaining the same thing over and over again.
Actually, the Quicktime container format forms the basis for the MPEG-4 standard (which is itself a container format).
MPEG-4 also suffers from confusion between "MPEG-4 the container format spec" and MPEG-4 the video compression codecs currently being used. Of course, the companies like to call it just MPEG-4 because it makes it sound better than MPEG, MPEG-2 and MP3.
Both Quicktime and WMF are moving towards or already do support MPEG-4. So perhaps one day each codec can be packaged only one and used with any MPEG-4 compatible container format.
Assuming Apple and Microsoft don't "improve" on the standard, of course.
Switching from Quicktime?
Oh dear, another ignorant soul who doesn't know the difference between the container format (Quicktime) and a codec (Sorenson).
Quicktime is just a wrapper around any codec you want to use. Currently that tends to be Sorenson 3 as its the best one shipped. I also watch various Divx movies that are in Quicktime format, since I installed the plugin that lets me do that.
Since he says it works on Mac OS, the chances are he already has a Quicktime plugin for his codec. Infact, he'd be insane *not* to package it in one of the major container formats as these have "install on demand" support.
User goes to a page with a movie in their wizzy new codec, and, if he can get the deal set up, Quicktime just says "you don't have the codec you need to see this movie click ok to download and install now?".
> What feature of Objective C makes templates unnecessary?
Confession time - I saw something that I was pretty sure would solve this when I was halfway through the objective C book, but I don't recall it off the top of my head. I posted a link to the book elsewhere on this page...
> It's somewhere in between C++ and Java in
> terms of cleanliness of the langauge
Certainly the syntax has some clunkiness here and there (how you define private methods springs to mind). I think overall I might be prepared to trade these inconveniences for much later binding than Java though...
>When I got mac OS 10.1, one of the docs
>said something about Objective C++,
>which sounds scary as hell...
Actually, I think all that is is a way to call libraries written in C++ from Objective C (and maybe vice-versa?). Not scary, actually pretty useful (be a bit annoying if all you could link to was other objective c libs or C but no C++ libs)
>That's why I think we need to shift some
>of the burden from class libraries to languages
I'm inclined to agree with you. Its nice to see "assert" becoming a keyword in Java rather than a library based kludge. And where would we be without try/catch/finally semantics.
Java Reflection is an example I have mixed feelings about. Its done (almost) entirely through classes, and it sure does feel clunky sometimes. But it landed in Java 1.1 without causing many problems (because it didn't change the language...)
Inner classes are an interesting one too. They did change the language, but not the runtime, because they were able to fake it in the compiler (actually, this is true for Java generics too, you have to use a special compiler, but it runs on straightup JDK 1.3/1.2).
In other words, its a hard balance to get right.
You're splitting hairs.
.NET Runtime. In practice almost everyone uses or will use it. It doesn't mean I wouldn't like to see more ppl using gcj, but currently its niche.
Of course it depends on who you are and what you want, but for most people most of the time, the libraries is where the action is at.
Technically, you're right, of course. You don't *need* stdclib, you don't need javax.* or STL. Its just that most of the time you'd want to use these things, unless your needs are specialised. [*]
Things like gjc are niche applications. Technically, you're right, you don't need the Java or
The reason people use it is because they perceive it will allow them to develop more complex applications more quickly (and hopefully more secure, and more robust etc). And that's what's relevant when comparing class libraries.
To some extent I'll shut my mouth over MFC, for indeed there I don't know how much more useful it is or isn't. In this context it doesn't really matter whether its a good library or not though. My point was that its a waste of time to compare languages if you should be comparing libraries. If you compare MFC and find its unnecessary, that's a valid thing to do...
[*] I'll give you that I should have been more specific. eg, a client side Java programmer probably doesn't need javax.*, but a server side programmer almost certainly will at some point. Sure, they could code it all from first principles, or java.* classes, but most people will never need to. So no, its not essential, its just "extremely useful". If one's splitting hairs, then yes, that's not the same thing.
If you want to know more about objective c, or to prepare before reading the books above, or to gain more depth of understanding of the language if the chapter or so spent in the above books doesn't explain enough, then look no further than this:
Object Oriented Programing and the Objective C language. Originally a Next Step book, now available free (HTML/PDF) at Apple.com or thru print on demand at Fatbrain.
There are tons of posts here saying Objective C has an ugly syntax.
;), but these people are too ignorant or blinkered to realise this.
.NET runtime or at least the Base Class Libraries. C is limited without sdtlib, C++ needs the STL or on MS platforms (shudder) MFC to get the full benefits.
What they mean is it doesn't look like C and C++ and Java.
Of course, how it looks has no bearing on how useful a language it is (heh, think Perl
Who cares what the syntax for calling a function is? So long as its not 3 pages of code its irrelevant.
Do we see any insightful comparison of the truly powerful language features from these people? Do we see discussions of how C, C#, C++, Java and Obvjective-C's approach to types and bindings work? How they support dynamic behaviour?
eg, I'm prepared to state that Objective-C makes generic types unnecessary, whereas C++ relies on them and Java is introducing them (slated for JDK 1.5). This is a good thing in C++, will be a good thing in Java, and I expect to see them in C# one day, because of commonality between how these languages are defined. Objective-C doesn't need them, it has another solution, more akin to Smalltalk.
We don't see this sort of comment (shallow though my example is) from most of the posters here because frankly all that they're experienced enough to comment on _is_ the syntax.
Even all that said - the features of the language pale into insignificance next to the quality of the class library. Java is nothing without the java.* and javax.* classes, C# is useless without the
This is a review of a book about Cocoa, not Objective-C. The class library, not the language. The class library will dominate any concern over the language used to program it. Learning a language takes days (or weeks if its something completely new to you like your first declarative functional or logical language). Learning a class library can take months or years (depending on the size).
Do yourself a favour and learn some more languages. Learn about languages. Use real class libraries. Then open your big mouth!
You are (both) quite right. I went and looked it up.
A little simple mathematics also proves it, RAMTOP on the 48K spectrum was 65535, which is of course (64 * 1024)-1 or a 64K address space, as you say.
Well, I wonder where I picked that idea up?
Nice to learn something new about something so far in my past.
In the UK, Sinclair computers and their derivtives were huge - much more well known than the US Timex TRS-XX machines (though geeks here seem to remember them fondly:
IIRC, all these machines had some Z-80 derivative:
ZX80 1K RAM (actually named after the year it came out)
ZX81 1K or 16K RAM
Spectrum (development codename ZX82) 16K or 48K RAM [+]
Spectrum + (larger, "better" keyboard)
Spectrum 128 (a vast 128K of RAM)
Spectrum 128 +2 (built in cassette deck!)
Spectrum 128 +3 (build in 3" *not 3.25"* 2 sided (by ejecting it and turning it over) floppy disk)
There were a couple of others.
Then also things like the
MGT Sam Coupe - which was compatible
I, my family or my firends owned every single one of these fine Z80 powered machines at one time or another. Hell, I learned to program in Sinclair basic. If Zilog have gone under (Chapter 11 doesn't mean its necessarily over) this is a sad day.
[+] actually this was a marketing lie. It had 32K RAM and 16K ROM with a unified address space. I think the 16K version had the same ROM, so it would be fairer to call that a 32K, if you want to include the total...
heh. Actually, I think I did the HTML version first then did Word. They want to print it, you see and lets face it, that's not HTML's strong point.
I work for a consultancy, which means my resume may go to the client also, and they're often banks, so it has too look good or it reflects badly on my employer. So Word/PDF end of discussion.
Maybe in 20 years...
Having just found a new job, I can say not a single employer I saw was not accepting email and/or web applications.
Of course, this is New York, it was an IT job and I saw all of the adds online. I'm sure your mileage will vary in other locations and industries.
And yes, they all wanted Word or PDF and they all printed them out for the interview, but its not exactly hard to print a file that's been emailled to you! This is more about people wanting hardcopy than anything else. I don't think most peoeple care whether that hardcopy is faxed to them or they have to print it out.
If that's so, its pretty weak.
Its a plugin technology - clearly the Quicktime player could be ported if there were *no* plugins available for any codec... it doesn't require Sorenson to operate. Hell, you can still open Cinepack Quicktime version 1 movies fine, last time I checked.
And similarly Sorenson could (if so inclined and able under their license agreements) make a plugin and test it using the OpenQuicktime or Quicktime 4 Linux stuff...
Incidentally, I remember when we first got Quicktime, on a floppy from Apple. System 7 days. 25 MHZ 680X0 processors 2-5 MB of Ram. 12" 256 colour screens & 9" monochrome. And there was Video! It was the size of a postage stamp, but it worked. Amazing...
You know - back then they didn't market it as a video technology? (though everyone knew it was). If I recall the original readme correctly, it talked about agnostic support for multiple simultaneous data streams, but they gave examples like "logging several scientific instruments together", not like "playing video and audio at the same time". LoL...
>PS2. 90% of the posts can be answered with this: >"complain with Sorenson to port the codec to Linux".
Unfortunately I think Apple require Sorenson to exclusively license their products to only Apple, at least as far as the decoders go. Otherwise I guess we might see Sorenson support in Windows Media Player or Real.
I know this was true for earlier Sorenson, can't see it having changed for 3.
So Apple are not off the hook...
As pointed out ad nauseum by people on the last story, QUICKTIME IS A CONTAINER FORMAT. It WRAPS different streams of audio and video.
The supported audio formats include WAV, AIFF, AU, mp3 and half a dozen others.
The video standards used have included CinePack, 3 different versions of Sorenson and even Intel's Indeo video (used for years in Microsoft AVIs).
The container format is supported on Linux Open Quicktime
The problem is Sorenson is exclusively licensed to Apple and they do not release it for Unix/Linux.
The other layer of ignorance is that MPEG-4 is also a container method for compressed audio and video streams. In fact its very similar to Quicktime (the packaging standard) indeed because it is actually _based on_ Quicktime!
That's not going to help Linux if they keep using Sorenson. It might help Mac users watch 3ivx, Divx and whatever other encoding formats are sometimes refered to as MPEG-4. You're not going to find this out from the CNET article though. Actually, since Quicktime is a container format, it supports pluggable codecs, so I watch MPEG4/{X}ivx video in Quicktime already - but it sure would be nice if Apple shipped those codecs out of the box.
The article is BS on many other points in any case - I would estimate over 50% of the streaming video I see out there is available in Quicktime format (though often alongside one of the other two). I mean, its very much the right tool for the right job at present... have you ever seen a good looking movie trailer in Real Video? I've seen a couple of OK ones, but the filesizes were similar to better looking Quicktime packaged (ie, Sorenson encoded) trailers. On the other hand I might use Real where image quality is less important. Oh, and of course, Quicktime includes mp3 support - its not competing with it!
So what does all this mean? Obviously Apple adopting MPEG4 could mean one of two things:
If Apple stick with pushing Sorenson as the primary codex (and hey, it is *really* nice looking) and don't ship any of the typical MPEG4 codecs, well that's not much news. If they ship {X}ivx alongside Sorenson, that's great because it allows content producers to choose, and Linux users can ask them to choose the more widely available {X}ivx compressors.
If I was more naive I'd say I can't believe CNET were presenting the "move" to MPEG4 as a retreat for Quicktime. MPEG 4 is the standardization of Quicktime and a vindication of its owenership of the professional market! Are they stupid or deliberately spinning it - you decide!
So all in all the CNET article is biased, tells you very little about what's actually been announced (is it new codecs? is it more standards compliance?) and tries to spin a victory as a defeat. Oh yeah, and Timothy's comments show he has no clue in this area either...
iirc the perceived problem is that the sample size is only 16 bits on regular CDs (some formats, like minidisc and sacd have larger sample sizes) so fine differences may get aliased to the same value.
These things have several related variables:
sample rate (44.1khz for cd)
sample size - (16 bit for cd) which determines
range of representable values
minimum difference between any 2 consecutive samples
I think its the later where CD sails close to (many say well inside of) what's perceptable by humans, and this is one of the things the newer formats try to address.
What were you compressing? Photographs?
:(
They're not intended to replace JPEG[*] they're best suited for application where you would use a GIF. As with GIF the compression is lossless and best for compressing line art and simple computer generated stuff.
In addition to GIF you also get:
* > 256 colours
* Full 8 bit alpha channel (but not in IE on Windows
Then there's MNG - for animated PNGs like animated GIFs and [*] JNG which in a PNG which internally uses uses JPEG compression and thus is pretty good with photos. These are more obscure though. I think JNG might allow transparency/alpha channel, which would be cool, as regular JPEG does not.
Can someone explain to me why Slashcode:
1/ limits us to 55 character subjects (55 ?!?)
2/ allows me to type 4 chars more than it actually accepts in the field, thus helpfully truncating whatever I can fit in the subject?
I know its only a few hundred miles, but you'd think anyone who acutally bothered to read the article would realize a bridge over the Thames in London that swayed a bit and one over the Tyne in Newcastle are in two completely different places?
I think this guy's a few chips short of a full butty myself...
I know its only a few hundred miles, but you'd think anyone who acutally bothered to read the article would realize a bridge over the Thames in London that swayed a bit and one over the Tyne in Newcastle are in two completely different places?
I think this guy's a few chips short of a full butty myself...
That's right, genius boy. You need to hire more people and buy additional hardware to open a port or to download a few song titles. Not. Wakeup call - we had a flat rate T1. They didn't care if we ran high bandwidth stuff like streaming audio - and we could, because real audio tunnels on port 80.
Anyway, its called "an example".
As in, an example of how stupid it is that people can stream audio or use dangerous RPC like services or whatever, so long as its port 80, but something *completely innocuous* and *low bandwidth* is blocked purely because its on a different port.
Both you, and that company, need hitting with a cluestick...
Heh, well I knew an admin at a 30 year old company (no .domb this one) who setup an mp3 jukebox with html interface for streaming to the whole office. YMMV :)
Besides, I can actually listen to music and work at the same time you know...
Here's the other thing that drives me crazy about this:
The overhead of all of the layers required to do RPC over HTTP (yes, I know it doesn't have to be HTTP, but that's what we're discussing here) is huge compared to the performance on raw sockets.
Secondly, the protocols in question are brand new. As are all the implementations. They haven't been audited, field tested or generally kicked around enough. Certainly not as much as the 30 year old ones, or even HTTP - and HTTP is very very simple - these are full function calling systems!
Sure, there's probably some benefit in that the modern protocols were designed with security in mind, and the older ones usually didn't consider it, but that won't protect us from design flaws or implementation bugs that there hasn't been time for the community to find.
So all in all I think all we did was bow to ignorance and introduce a lot of redundant overhead which is *less* proven secure than the older stuff.
Its funny, its so obviously the classic tradeoff between security and convenience. It seems people want these services, but they were insecure. So now they're still wanted, but just tunnelled through something to give everyone a *very probably false* sense of security.
Every large organization I've worked for is like that. They *will not* open new ports, but most of them pay no attention to what's going on on 80, 25 and the few other ports they do allow.
Its hardly surprising: they've all been sold on the all they need is a firewall. Then when they discover they need a policy for that firewall and for handling requests from their staff, they all choose to do "whatever everyone else does". This means HTTP, SMTP and POP bascially. (I'll refrain from commenting on how "secure" those three are.)
I was once told (at a previous job) I couldn't have CDDB because it was MP3-ish and might be used by music pirates. (In case you don't know, its a service for looking up the titles of songs, not getting the music itself. I explained this to the guy. He said "I know" but its still not happening.)
Actually the other thing that goes on is people outsource their firewall management. Every time you call you wait a week to get the person who knows their account, then they charge $$$ per hour to make a change. I think we found the real cause of my "no-CDDB" problem.