Perhaps it went something like this: SCO: You owe us money for Linux licenses. Google: Fuck off. SCO: You're using our code and we can prove it! Google: Go on then. SCO: No. Google: Fuck off then.
I'm well aware of the difference, but I was pointing out that finalize is the same name for every class. At least, it should be. If some idiot wants to call their finaliser "finish", it would be akin to making a C++ class with a "dispose" function that must be called before you delete it.
I'm not a fan of Swing, so I'll steer clear of that argument, however, I think you're over-simplifying by saying "MS could have easily fixed that problem" wrt the language extensions, because MS needed delegates to support the Win32 widget model and COM IIRC.
I quite like delegates and C# in general, but I'm still not fond of the way MS went about trying to polute Java.
"In Java, you still have to do memory management!!! despite what the literature says, if you don't make pointers NULL, then objects will not be deleted!!! You still have to check if those pointers are NULL, eitherwise your application will crash..." Err...no. I suggest you read up on Java's GC system.
"In Java, you can't use the RAII technique, so you have to explicitely 'shutdown' objects by calling a method of them which is named differently in each object, whereas in C++ the destruction of the stack-based object takes care of the side effects..." You mean "finalize()"?
"In Java, each cast is dynamic, since all methods are virtual by nature (unless declared final, of course). Applications that make heavy use of collections are much slower in Java than in C++, due to the cost of the dynamic cast. The slowness of a Java app rises proportionally to the number of casts the application has...the benchmarks certainly did not show that, did they?" That's only so true, since one of the things HotSpot does is "de-virtualize" methods which aren't overridden in the currently loaded classes.
Actually, I'm going to complain because you are completely wrong. Sun complained about Microsoft changing the language in a way that was incompatible with everybody else's implementation.
Err...The GIMP doesn't spawn separate toolbars for each image. It didn't in 1.2 and it didn't in 1.0 (Which is many, many years old). In fact, it doesn't even use toolbars as such, there's just a set of toolbox windows which aren't associated to any one image.
Netscape 4 was a disaster for both developers (Because its standards support was so poor/inconsistent and IE4 had much better CSS support) and users (Because it crashed too much), it's no surprise Netscape lost their leadership position. The sad thing is now that better stuff than IE is available, IE still rules the roost and looks set to for years yet.
Actually, my killer feature was Ogg support, but never mind. As for the jukebox, Rhythmbox does the job nicely. It does lack integration with my iRiver, but I intend to rectify that when I get the time.
As for "about" the same size, let's look at the features: iPod: 61(W) X 104(L) X 16(D)mm, weight 159 grams iHP-120: 60(W) X 105(L) X 19(D)mm, weight 160 grams
That's nothing. It's 3mm thicker, but still less than 2cm, that'll easily fit in any pocket that'll fit an iPod and there is essentially no weight difference.
OK, I can buy the cost of testing argument, but I don't get the confusion one. After all, any decent media player treats Ogg and MP3 files identically interface-wise, the only difference being the file extension.
"And yes, I understand the patent controversy surrounding MP3. But why exactly is it a patent uproar? Shouldn't people expect to be compensated for their work in creating something?" I just don't think you should be allowed to to patent maths.
"Even if you reverse-engineered the file format to create your encoders and players, the desire to do so wouldn't exist without the original work." How do you know? Lossy audio encoding's not something that sprang up because of MP3.
"And if by charging through the roof, you mean $0.75/unit for decoders, yes, I can see where Fraunhofer was being so harsh. In a $250-$500 player, that royalty can make or break a company. " And now suppose Faunhofer had decided to charge through the roof? Let's see, without Ogg Vorbis, what would the options be? WMA, which currently has to be decoded using Windows DLLs on Linux. Or, perhaps, AAC? Oh, wait, that's even more expensive.
"Besides, of the royalty free nature of Ogg is so great, then why does every Ogg player on the market also support MP3 (presumably paying Fraunhofer to do so)?" You are aware that MP3 got its foothold when people could get free MP3 encoders and decoders here, there and everywhere, aren't you? I doubt I would have gone for MP3 if I had to pay for an encoder.
"The fact of the matter is that 0.01% of Ogg users use it because they're convinced it's superior way to encode music. The rest of them do because they are contrary, self-important egomaniacs." And there we have it, Fortunato_NC demonstrating that tolerance of the opinions of others is not something he holds in high regard.
"Ogg as a technology is unimportant, no matter how many soon-to-be out of business Korean electronics manufacturers support it, because (almost) NO ONE CARES ABOUT IT!" Tell that to Epic. Tell that to iRiver. Tell that to Rio. Tell that to Neuros. If "(almost) NO ONE CARES ABOUT IT", then why do manufacturers support it?
Quite some time ago, when Linux was first put onto the iPod, an early version of Tremor (An integer-only Vorbis decoder) was running at around 80% realtime. Seeing as there have been various performance and memory optimisations during that time, it's possible they may be able to get it to work.
Oh, the general populace isn't aware of AAC's existance either and there's still plenty of room on the iPod's firmware, so why not?
Do you have any idea about the history of Ogg? MP3 is patented in countries which allow such silliness. When people started getting nasty letters about paying for an MP3 encoder they wrote from scratch, somebody noticed and decided to build something completely free.
Formats such as Ogg prevent the big companies from charging extortionate licensing fees, since everyone would just follow Epic's lead and go to Ogg if Microsoft and the MPEG group started charging through the roof.
Oh, and how's this for a deal breaker; Ogg support, twice the battery life, a better remote control, an FM radio and a built-in microphone? Ogg support alone was what swung me to get an iRiver, since I'm not going to re-encode all my Oggs just so I can use an iPod, especially since, being a Linux user, I don't get the benefit of iTunes.
It's not a "new" feature, iRiver have had record-to-MP3 for quite some time now. IIRC it started with their iFP-300 series, which is getting on a bit now.
No, I'm saying PAL itself is not that great, and when you add in compression artifacts due to the bitrate digital TV is encoded at, the quality is even worse. One would hope that HDTV signals have a better encoding method or higher bitrate, but we shall see.
PAL isn't great either these days, especially when you can see the compression artifacts on digital TV. Sometimes I wish I weren't so techy, then they wouldn't bug me and I probably wouldn't notice them.
You don't, because of the way virtual memory works. Let's assume you have a 16-bit address space, &0000-&FFFF. Now, each and every application gets 64MB of VM to play with. Now, if you memory-map a file to &F000-&FFFF, it doesn't actually take up RAM. When you attempt to write to those locations, data will be written to the file instead of to RAM.
Virtual memory addresses don't necessarily correspond to phyisical memory addresses.
It will indeed fix it. HURD handles storage devices (Hard disks, CDs, etc) by memory mapping them into the address space. In a 32-bit system, you can only address 4GB (Forgetting such systems as PAE), thus HURD can't handle very big partitions on 32-bit systems. However, if you move to 64-bit, it become feasible with todays storage systems, along with tomorrow's for some time to come.
Slashdot Mirror
Well, if you insist on stalking me, you can expect as much :P
Oh mighty AC, make me cower some more.
Perhaps it went something like this:
SCO: You owe us money for Linux licenses.
Google: Fuck off.
SCO: You're using our code and we can prove it!
Google: Go on then.
SCO: No.
Google: Fuck off then.
Repeat as necessary.
I'm well aware of the difference, but I was pointing out that finalize is the same name for every class. At least, it should be. If some idiot wants to call their finaliser "finish", it would be akin to making a C++ class with a "dispose" function that must be called before you delete it.
You could say the same is true of Java.
I'm not a fan of Swing, so I'll steer clear of that argument, however, I think you're over-simplifying by saying "MS could have easily fixed that problem" wrt the language extensions, because MS needed delegates to support the Win32 widget model and COM IIRC.
I quite like delegates and C# in general, but I'm still not fond of the way MS went about trying to polute Java.
"In Java, you still have to do memory management!!! despite what the literature says, if you don't make pointers NULL, then objects will not be deleted!!! You still have to check if those pointers are NULL, eitherwise your application will crash..."
Err...no. I suggest you read up on Java's GC system.
"In Java, you can't use the RAII technique, so you have to explicitely 'shutdown' objects by calling a method of them which is named differently in each object, whereas in C++ the destruction of the stack-based object takes care of the side effects..."
You mean "finalize()"?
"In Java, each cast is dynamic, since all methods are virtual by nature (unless declared final, of course). Applications that make heavy use of collections are much slower in Java than in C++, due to the cost of the dynamic cast. The slowness of a Java app rises proportionally to the number of casts the application has...the benchmarks certainly did not show that, did they?"
That's only so true, since one of the things HotSpot does is "de-virtualize" methods which aren't overridden in the currently loaded classes.
You don't think Java has reflection?! Oh dear...
Actually, I'm going to complain because you are completely wrong. Sun complained about Microsoft changing the language in a way that was incompatible with everybody else's implementation.
Err...The GIMP doesn't spawn separate toolbars for each image. It didn't in 1.2 and it didn't in 1.0 (Which is many, many years old). In fact, it doesn't even use toolbars as such, there's just a set of toolbox windows which aren't associated to any one image.
Netscape 4 was a disaster for both developers (Because its standards support was so poor/inconsistent and IE4 had much better CSS support) and users (Because it crashed too much), it's no surprise Netscape lost their leadership position. The sad thing is now that better stuff than IE is available, IE still rules the roost and looks set to for years yet.
There has never been a portable music player that could store all of my music at a price point anywhere near $30.
Actually, my killer feature was Ogg support, but never mind. As for the jukebox, Rhythmbox does the job nicely. It does lack integration with my iRiver, but I intend to rectify that when I get the time.
As for "about" the same size, let's look at the features:
iPod: 61(W) X 104(L) X 16(D)mm, weight 159 grams
iHP-120: 60(W) X 105(L) X 19(D)mm, weight 160 grams
That's nothing. It's 3mm thicker, but still less than 2cm, that'll easily fit in any pocket that'll fit an iPod and there is essentially no weight difference.
OK, I can buy the cost of testing argument, but I don't get the confusion one. After all, any decent media player treats Ogg and MP3 files identically interface-wise, the only difference being the file extension.
That's interesting, seeing as my iHP-120 is roughly the same size as my friend's iPod...
"And yes, I understand the patent controversy surrounding MP3. But why exactly is it a patent uproar? Shouldn't people expect to be compensated for their work in creating something?"
I just don't think you should be allowed to to patent maths.
"Even if you reverse-engineered the file format to create your encoders and players, the desire to do so wouldn't exist without the original work."
How do you know? Lossy audio encoding's not something that sprang up because of MP3.
"And if by charging through the roof, you mean $0.75/unit for decoders, yes, I can see where Fraunhofer was being so harsh. In a $250-$500 player, that royalty can make or break a company. "
And now suppose Faunhofer had decided to charge through the roof? Let's see, without Ogg Vorbis, what would the options be? WMA, which currently has to be decoded using Windows DLLs on Linux. Or, perhaps, AAC? Oh, wait, that's even more expensive.
"Besides, of the royalty free nature of Ogg is so great, then why does every Ogg player on the market also support MP3 (presumably paying Fraunhofer to do so)?"
You are aware that MP3 got its foothold when people could get free MP3 encoders and decoders here, there and everywhere, aren't you? I doubt I would have gone for MP3 if I had to pay for an encoder.
"The fact of the matter is that 0.01% of Ogg users use it because they're convinced it's superior way to encode music. The rest of them do because they are contrary, self-important egomaniacs."
And there we have it, Fortunato_NC demonstrating that tolerance of the opinions of others is not something he holds in high regard.
"Ogg as a technology is unimportant, no matter how many soon-to-be out of business Korean electronics manufacturers support it, because (almost) NO ONE CARES ABOUT IT!"
Tell that to Epic. Tell that to iRiver. Tell that to Rio. Tell that to Neuros. If "(almost) NO ONE CARES ABOUT IT", then why do manufacturers support it?
Quite some time ago, when Linux was first put onto the iPod, an early version of Tremor (An integer-only Vorbis decoder) was running at around 80% realtime. Seeing as there have been various performance and memory optimisations during that time, it's possible they may be able to get it to work.
Oh, the general populace isn't aware of AAC's existance either and there's still plenty of room on the iPod's firmware, so why not?
Do you have any idea about the history of Ogg? MP3 is patented in countries which allow such silliness. When people started getting nasty letters about paying for an MP3 encoder they wrote from scratch, somebody noticed and decided to build something completely free.
Formats such as Ogg prevent the big companies from charging extortionate licensing fees, since everyone would just follow Epic's lead and go to Ogg if Microsoft and the MPEG group started charging through the roof.
Oh, and how's this for a deal breaker; Ogg support, twice the battery life, a better remote control, an FM radio and a built-in microphone? Ogg support alone was what swung me to get an iRiver, since I'm not going to re-encode all my Oggs just so I can use an iPod, especially since, being a Linux user, I don't get the benefit of iTunes.
It's not a "new" feature, iRiver have had record-to-MP3 for quite some time now. IIRC it started with their iFP-300 series, which is getting on a bit now.
No, I'm saying PAL itself is not that great, and when you add in compression artifacts due to the bitrate digital TV is encoded at, the quality is even worse. One would hope that HDTV signals have a better encoding method or higher bitrate, but we shall see.
Yep, my bad, I just had MB stuck in my head.
PAL isn't great either these days, especially when you can see the compression artifacts on digital TV. Sometimes I wish I weren't so techy, then they wouldn't bug me and I probably wouldn't notice them.
You don't, because of the way virtual memory works. Let's assume you have a 16-bit address space, &0000-&FFFF. Now, each and every application gets 64MB of VM to play with. Now, if you memory-map a file to &F000-&FFFF, it doesn't actually take up RAM. When you attempt to write to those locations, data will be written to the file instead of to RAM.
Virtual memory addresses don't necessarily correspond to phyisical memory addresses.
It will indeed fix it. HURD handles storage devices (Hard disks, CDs, etc) by memory mapping them into the address space. In a 32-bit system, you can only address 4GB (Forgetting such systems as PAE), thus HURD can't handle very big partitions on 32-bit systems. However, if you move to 64-bit, it become feasible with todays storage systems, along with tomorrow's for some time to come.
Actually, that only worked for Gtk themes based of the default or pixmap engines.