I am aware that the EMT64 extensions are exactly the same as x86_64. IF THEY WEREN'T THEY'D BE USELESS FOR RUNNING THE 64 BIT CODE... which is why Intel included them.
But Intel didn't change any of their cores, IIRC. Just the microcode inside so it could decode and emulate those instructions.
They weren't "copying" them, because they were just giving into OEM/custmer pressure and re-provisioned the internal chip resources into decoding the instruction set. Of course, doing this all quietly with little fanfare because of the NIH syndrome.
As an aside, one thing that could save the netburst core would be if they truly changed the microcode to run a vastly different IA with a much larger register file, nay a windowed register file... one that puts integer, FPU and SIMD instructions all on equal footing too. This could provide chances for greater internal parallelism and less traffic to the caches.
It's not at all compatible with OpenFirmware, and that's a damn shame.
Because what makes OpenFirmware so great is that you can take any hardware (graphics card, scsi card, etc.), plop an FCODE ROM on it, and it can be used AT BOOT by any type of machine that is OpenFirmware compliant. Now that doesn't remove the need to write native OS drivers, but at least you wouldn't have that needless Mac AND PC versions of video cards or whatever... just OF-compatible cards.
But not until later, when they were tweaking the system bus to run at 60MHz. This yielded the 60 MHz, 90 MHz (I had this one), 120 and 180 MHz pentiums.
The Pentium was not copying anything done by AMD (AMD was pushing a P6-like design from a company they purchased in the K5/K6 cores)
Now the P6 could be considered a copy of the K6. That I'll believe.
And the EMT64 was not really a "copy" but a tweak in the microcode of the P4 to appease Microsoft and consumers who wanted to take advantage of the larger register set and memory space that x86_64 long mode affords. Internally, the P4 has the "features" required to make this work, but Intel did not try especially hard to make these extended features run fast in their CPUs, as if to downplay it.
OpenGL vs. Direct3D has nothing to do with the choice between Intel vs AMD. Either you're pulling this shit out of your ass, or you're very confused.
And the AMD for games and Intel for business/video logic is equally retarded... (I will allow that the best video encoding WILL be found on P4s most times)
Maybe they realized they weren't going to be able to reliably cool the netburst architecture at those speeds so they're going to have to switch to the lower-clocked, possibly multicore Pentium-M arch.
They'd be FORCED to use a numbering scheme because any conspicuous lowering of the MHz would cause Joe Shmoe to say "What the hell?"
Apparently they have an experimental patch wherein you can boot a "panic" kernel if you get a kernel panic. Sounds like a neat idea -- configure your UP kernel as the panic kernel for emergency situations. The machine would "reboot" on it's own, much faster than if a watchdog triggered and cycled the power.
I don't know why people get all worked up about it. 1) Passive RFID only works in a very short range. Making it work long range (> 3 feet) involves really expensive (and noticable) equipment. 2) You can easily detect Passive RFID scanners because they send out RF energy. 3) Passive RFID can't be used on crowds (too many tags screws it up)
Active RFID I'd be concerned about. With that you can do stuff like ultra-wideband transmission to avoid noise and interference, yadda yadda yadda. And you can't tell who's listening.
Parrot's runtime sounds a whole lot like what Mathematica does internally: dynamically typed language which compiles JIT into a bytecode for a register-windowing VM.
MP3s are not designed to be gapless. There's only two frame sizes, and you're screwed if the end of one song doesn't coincide with the end of a frame... the encoder will have guessed as to what the rest of it should be filled (probably silence).
There's basically one way to handle it. You encode the exact length of the decoded song in samples into extended ID3 tags. LAME started doing this and all the major software players and the Karma (specifically) can read these tags, and thus know exactly when to cut that last frame short and stick in the first frame of the next track.
All the other formats define the handling of this detail in the format itself.
that they are trying to give you the best of both worlds. Expressions that can be expressed simply in SQL have short forms in the language too. Expressions that were hard to express in SQL but easy in R.A. are still pretty basic forms. By not trying to be like SQL, and more like {T,PL}SQL, I think they get the freedom they need.
For all that Rel (Tutorial D) wants to be, I don't understand this obsession with NULLs.
I think the concept of null values is very sound, and how they behave in comparisons makes perfect sense.
Just put non-null constraints by default on the structures in the language, and then provide a way to mark relational fields as possibly having NULL values. Can they at least allow that?:-)
I think he's trying to say that joins shouldn't be this hard to describe in the language. Compare the symbolic forms: Example, theta join And the implementation in SQL: SQL join example
Specifically in Tutorial D (and hence Rel) you would do this:
this proposed language is like a superset of sql. It also sort mixes itself with PL/SQL-like constructs as well. I think it's rather novel and it could make your optimization tasks easier if you had access to something like this... less trying to think in terms of the language, more in terms of how you want to acutally manipulate the data.
This is _not_ a query builder. It's going back, looking at what relational algebra is, seeing what people do with SQL, and then making sure the language has all the idioms required to be "complete" and not arbitrary.
10 years ago. Actually, I think AC3 is another (related) shitty format, but one thing saves it: directional quantization for 5.1 sound... a novel feature.
ATRAC3+ may be great at 192, and maybe it uses more advanced techniques to model sound than it used to and sounds just as good as 256 MP3 or 192 AAC or OGGs, but you know what?
I can get unencumbered encoders and decoders for all of those formats.
ATRAC3 doesn't. So it loses.
And in my opinion, yes, 128kbps ABR OGG beats 132kbps ATRAC3+ in listening tests.
Gapless is a strawman. OGG and MP3 can play gapless. Player support is lacking with the exception of the Karma, but that has nothing to do with my criticism of the format.
I'd buy an MD player if it could play other formats...
I was unaware that MSN/AOL/yahoo had moved on to internal solutions. At one time they did piggyback on netmeeting. IIRC, ICQ was probably the first offender, where you could use netmeeting as a "plugin".
Actually, I think email is a less suitable medium than instant messaging for file transfers. Because the MIME-encoding methods by which files are attached to emails is quite cumbersome. Messaging applications can just exchange some very basic metadata through the central server, and then the transfer occurs in a simplistic fashion at wire speed. That is, transferring files a trivial internet application, but announcing and setting up the transaction is difficult. The chat sssion is perfect, as the setup is conducted by means of both parties being physically present, and the intermediate server acts a reference point, so it can be coordinated even if both parties are behind a firewall.
Similarly, it follows that video teleconferencing is another natural thing to enable in a chat session. But there is nothing about the video chat that crosses into the messaging component of instant messaging. IM should work on my phone in my car, just as well as it does in my house on my broadband connection.
(Why file transfer over video? Well, file transfer can be accomodated over slow, intermittent lines even without a streaming protocol, say though TFTP... so there's no reason why not to have it everywhere. Especially when you use it trade small artifacts, like business cards or maybe an screenshot from your webcam... etc.)
I'm not saying real time video isnt's not a good feature, but it shouldn't be considered a REQUIREMENT.
I mean, what do people do on IM when they're at work and they don't have a webcam? Do they beg their boss to buy them one? Give me a break.
40 gigs. No bs software. optical I/O, wav recording. long battery life. indestructible. Firmware isn't open source but doesn't mean it's bad. Only yearning for gapless playback... sigh.
iRiver. Audio enthusiast reviews consistently put iRiver on top of the iPod. I've seen no karma vs. iriver audio quality comparisons, and not many karma vs. iPod. More investigation reveals it's really a matter of the chipset.. that being said, they all sound just fine. Most people can't tell. As is always it helps MOST to ditch the included headphones.
All three support every OS. It depends on how you want to talk to it. iPods can work like a firewire drive or USB mass-storage device and there is some open source software that can fiddle with the database. Karmas use java software to do everything. The iRiver is also a USB mass-storage device... and the database is open and there are a few open source packages to manage that too (better than the included ones!)
iPod will be the only player you'll be able to use with files you downloaded from iTunes. Interface is arguably the best. Also the smallest. But it has the shortest battery life. Supports AAC, but not FLAC or OGG.
Karma can be managed from anywhere on a home network (but unfortunately, it can't be controlled remotely). Supports FLAC and OGG, among others. Java interface used for management, supports any OS. But you can't use it like an external drive. Some reliability issues.
iRiver functions as an external drive (very useful), so it is OS-agnostic. Has optical outputs which can be useful in conjunction with a stereo, but it too lacks remote operation. Nice handheld remote, accessories. Supports OGG, not FLAC. Can encode MP3s from optical/mic input. Hardy as hell.
However, I think there may be some mis-understanding as my comments are primarily addressing this: http://slashdot.org/comments.pl?sid=125289& cid=105 00125
Unless this person is _you_, and if so I apologize if I sounded harsh. But I do feel that in general, not supporting teleconferencing does not seem like priority one for GAIM or trillian. I would rather they support fully and completely the subset critical features common to all messaging protocols (text, markup, encryption, direct connect/file exchange, presence notification). Otherwise, why get a 3rd party client? If I wanted all the MSN whiz-bang things, I'd just use MSN. If I want most of the features supported across networks in a small footprint, I'll use the 3rd party tool.
And if you wanna chat me up, I'll install gnome-meeting just for you. ^_^
1) m3u support, nat, which is nice if you're using winamp or xmms to manage your collection DIRECTLY ON THE DEVICE. ^_^
2) db which lets you search on attribs on the fly... I haven't really used this but apparently it's nice
3) something I really appreciate on the iRiver-made firmwares... you retain any and all previously played songs, and you can go forward to any songs your back-pedaled over... like the forward and backwards buttons on your browser. I forget if the iPod or Karma does this.
It's bigger, but it holds 40GB, and it's very hardy. I've dropped, tossed it into backpacks, taken it to the gym, used it on riding mowers, etc. etc. with nary a skip. Also, the remote is quite nice; underrated IMHO. It is a simple USB 2.0 mass-storage device, which is very wise.
Slashdot Mirror
I am aware that the EMT64 extensions are exactly the same as x86_64. IF THEY WEREN'T THEY'D BE USELESS FOR RUNNING THE 64 BIT CODE... which is why Intel included them.
But Intel didn't change any of their cores, IIRC. Just the microcode inside so it could decode and emulate those instructions.
They weren't "copying" them, because they were just giving into OEM/custmer pressure and re-provisioned the internal chip resources into decoding the instruction set. Of course, doing this all quietly with little fanfare because of the NIH syndrome.
As an aside, one thing that could save the netburst core would be if they truly changed the microcode to run a vastly different IA with a much larger register file, nay a windowed register file... one that puts integer, FPU and SIMD instructions all on equal footing too. This could provide chances for greater internal parallelism and less traffic to the caches.
It's not at all compatible with OpenFirmware, and that's a damn shame.
Because what makes OpenFirmware so great is that you can take any hardware (graphics card, scsi card, etc.), plop an FCODE ROM on it, and it can be used AT BOOT by any type of machine that is OpenFirmware compliant. Now that doesn't remove the need to write native OS drivers, but at least you wouldn't have that needless Mac AND PC versions of video cards or whatever... just OF-compatible cards.
But not until later, when they were tweaking the system bus to run at 60MHz. This yielded the 60 MHz, 90 MHz (I had this one), 120 and 180 MHz pentiums.
The Pentium was not copying anything done by AMD (AMD was pushing a P6-like design from a company they purchased in the K5/K6 cores)
Now the P6 could be considered a copy of the K6. That I'll believe.
And the EMT64 was not really a "copy" but a tweak in the microcode of the P4 to appease Microsoft and consumers who wanted to take advantage of the larger register set and memory space that x86_64 long mode affords. Internally, the P4 has the "features" required to make this work, but Intel did not try especially hard to make these extended features run fast in their CPUs, as if to downplay it.
What the hell are you talking about?
OpenGL vs. Direct3D has nothing to do with the choice between Intel vs AMD. Either you're pulling this shit out of your ass, or you're very confused.
And the AMD for games and Intel for business/video logic is equally retarded... (I will allow that the best video encoding WILL be found on P4s most times)
Maybe they realized they weren't going to be able to reliably cool the netburst architecture at those speeds so they're going to have to switch to the lower-clocked, possibly multicore Pentium-M arch.
They'd be FORCED to use a numbering scheme because any conspicuous lowering of the MHz would cause Joe Shmoe to say "What the hell?"
http://www.xmission.com/~ebiederm/files/kexec/
Apparently they have an experimental patch wherein you can boot a "panic" kernel if you get a kernel panic.
Sounds like a neat idea -- configure your UP kernel as the panic kernel for emergency situations. The machine would "reboot" on it's own, much faster than if a watchdog triggered and cycled the power.
I don't know why people get all worked up about it.
1) Passive RFID only works in a very short range. Making it work long range (> 3 feet) involves really expensive (and noticable) equipment.
2) You can easily detect Passive RFID scanners because they send out RF energy.
3) Passive RFID can't be used on crowds (too many tags screws it up)
Active RFID I'd be concerned about. With that you can do stuff like ultra-wideband transmission to avoid noise and interference, yadda yadda yadda. And you can't tell who's listening.
Really.
Parrot's runtime sounds a whole lot like what Mathematica does internally: dynamically typed language which compiles JIT into a bytecode for a register-windowing VM.
i was focusing on the non-short-circuiting nature of it, which is critical.
MP3s are not designed to be gapless. There's only two frame sizes, and you're screwed if the end of one song doesn't coincide with the end of a frame... the encoder will have guessed as to what the rest of it should be filled (probably silence).
There's basically one way to handle it. You encode the exact length of the decoded song in samples into extended ID3 tags. LAME started doing this and all the major software players and the Karma (specifically) can read these tags, and thus know exactly when to cut that last frame short and stick in the first frame of the next track.
All the other formats define the handling of this detail in the format itself.
It just means "unknown". Not N/A. But "unknown".
In a T/F column, it's not true, and it's not false. It _never_ short circuits and expression, behaving as TRUE with ANDs and FALSE with ORs.
I think it's great.
that they are trying to give you the best of both worlds. Expressions that can be expressed simply in SQL have short forms in the language too. Expressions that were hard to express in SQL but easy in R.A. are still pretty basic forms.
By not trying to be like SQL, and more like {T,PL}SQL, I think they get the freedom they need.
Solaris 8 Kernel Module Programming
For all that Rel (Tutorial D) wants to be, I don't understand this obsession with NULLs.
:-)
I think the concept of null values is very sound, and how they behave in comparisons makes perfect sense.
Just put non-null constraints by default on the structures in the language, and then provide a way to mark relational fields as possibly having NULL values. Can they at least allow that?
Compare the symbolic forms:
Example, theta join
And the implementation in SQL:
SQL join example
Specifically in Tutorial D (and hence Rel) you would do this:And subsequently do shit with T1. That's it.
this proposed language is like a superset of sql. It also sort mixes itself with PL/SQL-like constructs as well. I think it's rather novel and it could make your optimization tasks easier if you had access to something like this... less trying to think in terms of the language, more in terms of how you want to acutally manipulate the data.
This is _not_ a query builder. It's going back, looking at what relational algebra is, seeing what people do with SQL, and then making sure the language has all the idioms required to be "complete" and not arbitrary.
Oh yeah, and the added cat ears. Silly goose...
10 years ago. Actually, I think AC3 is another (related) shitty format, but one thing saves it: directional quantization for 5.1 sound... a novel feature.
ATRAC3+ may be great at 192, and maybe it uses more advanced techniques to model sound than it used to and sounds just as good as 256 MP3 or 192 AAC or OGGs, but you know what?
I can get unencumbered encoders and decoders for all of those formats.
ATRAC3 doesn't. So it loses.
And in my opinion, yes, 128kbps ABR OGG beats 132kbps ATRAC3+ in listening tests.
Gapless is a strawman. OGG and MP3 can play gapless. Player support is lacking with the exception of the Karma, but that has nothing to do with my criticism of the format.
I'd buy an MD player if it could play other formats...
I was unaware that MSN/AOL/yahoo had moved on to internal solutions. At one time they did piggyback on netmeeting. IIRC, ICQ was probably the first offender, where you could use netmeeting as a "plugin".
Actually, I think email is a less suitable medium than instant messaging for file transfers. Because the MIME-encoding methods by which files are attached to emails is quite cumbersome. Messaging applications can just exchange some very basic metadata through the central server, and then the transfer occurs in a simplistic fashion at wire speed. That is, transferring files a trivial internet application, but announcing and setting up the transaction is difficult. The chat sssion is perfect, as the setup is conducted by means of both parties being physically present, and the intermediate server acts a reference point, so it can be coordinated even if both parties are behind a firewall.
Similarly, it follows that video teleconferencing is another natural thing to enable in a chat session.
But there is nothing about the video chat that crosses into the messaging component of instant messaging. IM should work on my phone in my car, just as well as it does in my house on my broadband connection.
(Why file transfer over video? Well, file transfer can be accomodated over slow, intermittent lines even without a streaming protocol, say though TFTP... so there's no reason why not to have it everywhere. Especially when you use it trade small artifacts, like business cards or maybe an screenshot from your webcam... etc.)
I'm not saying real time video isnt's not a good feature, but it shouldn't be considered a REQUIREMENT.
I mean, what do people do on IM when they're at work and they don't have a webcam? Do they beg their boss to buy them one? Give me a break.
40 gigs. No bs software. optical I/O, wav recording. long battery life. indestructible. Firmware isn't open source but doesn't mean it's bad. Only yearning for gapless playback... sigh.
iRiver. Audio enthusiast reviews consistently put iRiver on top of the iPod. I've seen no karma vs. iriver audio quality comparisons, and not many karma vs. iPod. More investigation reveals it's really a matter of the chipset.. that being said, they all sound just fine. Most people can't tell. As is always it helps MOST to ditch the included headphones.
All three support every OS. It depends on how you want to talk to it. iPods can work like a firewire drive or USB mass-storage device and there is some open source software that can fiddle with the database. Karmas use java software to do everything. The iRiver is also a USB mass-storage device... and the database is open and there are a few open source packages to manage that too (better than the included ones!)
iPod will be the only player you'll be able to use with files you downloaded from iTunes. Interface is arguably the best. Also the smallest. But it has the shortest battery life. Supports AAC, but not FLAC or OGG.
Karma can be managed from anywhere on a home network (but unfortunately, it can't be controlled remotely). Supports FLAC and OGG, among others. Java interface used for management, supports any OS. But you can't use it like an external drive. Some reliability issues.
iRiver functions as an external drive (very useful), so it is OS-agnostic. Has optical outputs which can be useful in conjunction with a stereo, but it too lacks remote operation. Nice handheld remote, accessories. Supports OGG, not FLAC. Can encode MP3s from optical/mic input. Hardy as hell.
I think it's great for the deaf.
& cid=105 00125
However, I think there may be some mis-understanding as my comments are primarily addressing this:
http://slashdot.org/comments.pl?sid=125289
Unless this person is _you_, and if so I apologize if I sounded harsh. But I do feel that in general, not supporting teleconferencing does not seem like priority one for GAIM or trillian. I would rather they support fully and completely the subset critical features common to all messaging protocols (text, markup, encryption, direct connect/file exchange, presence notification).
Otherwise, why get a 3rd party client? If I wanted all the MSN whiz-bang things, I'd just use MSN. If I want most of the features supported across networks in a small footprint, I'll use the 3rd party tool.
And if you wanna chat me up, I'll install gnome-meeting just for you. ^_^
Some interesting features:
1) m3u support, nat, which is nice if you're using winamp or xmms to manage your collection DIRECTLY ON THE DEVICE. ^_^
2) db which lets you search on attribs on the fly... I haven't really used this but apparently it's nice
3) something I really appreciate on the iRiver-made firmwares... you retain any and all previously played songs, and you can go forward to any songs your back-pedaled over... like the forward and backwards buttons on your browser. I forget if the iPod or Karma does this.
It's bigger, but it holds 40GB, and it's very hardy. I've dropped, tossed it into backpacks, taken it to the gym, used it on riding mowers, etc. etc. with nary a skip. Also, the remote is quite nice; underrated IMHO. It is a simple USB 2.0 mass-storage device, which is very wise.