According to Wikipedia, for an 'excellent' human eye the PC World analyst is correct; however for us average joes with 20/20 vision (or worse) Apple's claims are accurate:-
For a human eye with excellent acuity, the maximum theoretical resolution is 50 CPD[32] (1.2 arcminute per line pair, or a 0.35 mm line pair, at 1 m).
...A resolution of 2 arcminutes per line pair, equivalent to a 1 arcminute gap in an optotype, corresponds to 20/20 (normal vision) in humans
If my math is correct then this is 60% worse than the 'excellent' eye; so the figure of 477 ppi at 12 inches is 286.2ppi; so well within the retina display's capability.
It's Apple's OS, they developed it, spend years and millions of $$$ making it - why shouldn't they be allowed to say what machines can and can't run it?
These arguments about "I'd buy a Mac if it had exactly X configuration, but seeing as they don't I'll just pirate it on my own system" have absolutely zero merit. Just because the developers of Windows and Linux have chosen to let you run their OS on any x86 machine, doesn't mean you automatically have the right to run any piece of software you like on your machine.
What I mean by passive detection systems is anything like an optical camera which does not need to emit anything to see something. I am not sure what technologies could be used, but while hiding is a good thing, being able to 'see' is just as important.
An optical camera relies on light coming from or reflect off an object to see it. Light only travels a matter of a few metres underwater, and to hear another vessel (i.e. SONAR) that vessel needs to be emitting some sound; which these submarines are designed to minimise.
My point is that there isn't really *a* x86 ABI. It's an application level interface, and so it is defined by the operating system and associated environment. You are correct that the Mach-O (OS X) ABI is different that the Linux/*BSD or even the Windows one, but that's purely down to the OS design, not the CPU design.
Plenty of embedded systems which use x86 chips have their own ABI, with greater or lesser amounts of rules.
Note: The ABI (Application Binary Interface) isn't defined by the chip, it's defined by the Operating System. Linux generally uses the System V ABI (on x86), simply because it was easier to use a common ABI than invent your own. Keeping the Linux ABI for x86-64 similar to the x86 one makes the whole toolchain much easier to develop.
There is nothing stopping you from calling functions in any way you see fit, saving and restoring no information if you want, but you'll have fun when interfacing with other pre-compiled libraries. Most of the stuff in the ABI is there for a good reason, and the optional stuff (previous stack frame) can generally be disabled with the appropriate optimisation setting in your compiler.
I see no mention of virtualisation techiques that virtualise a different architecture - such as Transitive's QuickTransit software, of Rosetta fame. They announced a version of their software the other day which virtualises a SPARC Solaris machine on x86-64 Linux, which sounds more interesting than simply pretending to be yourself:)
Note that in their test AnandTech were running the Yonah and X2 in a desktop motherboard, with a fast PCIe graphics card, desktop HDD to make a fair comparision with thier previous Dothan review - see here for tech specs.
Also note that the power consumption figures quoted are total system.so the majority of that power will be driving the rest of the PC, not the CPU. This is why the difference doesn't look very big between the Yonah and X2. However, if you could get figures for the just the CPU (which isn't very easy to do in this sort of review), I think we'd see a different story...
Note: although there are only 24 physical frames every sec, the shutter actually runs at twice this speed (i.e. each frame is displayed twice), so the shutter speed is 48fps. A shutter speed of only 24 fps, projecting on such a large arc of vision would look terrible!
Well I refer back to the underground cinema screen with _no_ reception - is the doctor/ user of a medical monitor going to sue becuase their phone didn't work? If so then something is definitely wrong.
The example that everyone uses of a doctor is bogus really - if a doctor is on call then they have to be able to take that call - if a cinema puts up a notice - publicly in the lobby before you go in - saying mobiles are not permitted, then they have evey right to enforce that policy in their own cinema - if the doctor doesn't like it then they can go to another cinema.
The blocking of mobiles in non-public places such as cinemas, theatres and the like is up to the owner of the cinema etc. It's just like any other conditions of sale such as no smoking - no-one is forcing you to go to that cinema and have your phone blocked, it's just that if you do, then that's what will happen.
The nature of supply and demand wil then determine if these mesaures are sucessful or not - if people don't want to have their phone blocked in a cinema, then they will go to another. However, I know at least one person that would patronise such a cinema.
What about if the doctor went to the cinema and the local cell transmitter went down? Cell-phones have no SLA (service level agreement), so a doctor has no guarantee that he will get service in the cinema anyway. Plus when I worked in a cinema here in the UK, we had a scren that was underground, and you couldn't get reception there _ever_!
The way I see it, if a cinema puts up a notice saying that cellphones are not allowed in the auditorium, then there's nothing wrong with them using technology to inforce it - it's no different than having the usher(s) kick people out that use them.
First the PATRIOT act, and now this - is there some kind of law in the U.S. that mandates that every bill's name has to make some clever (read: daft) acronym? As a UK citizen, I'm not hugely exposed to US legislation, but the UK government's bills generally speaking don't have such overly long names, whose only purpose seems to confuse the actual purpose of the bill and give it a cool acronym...
As subject, this torrent is actually the linux kernel ver 2.6.2!
all these benchmarks running in 32bit mode
on
Athlon 64 Debuts
·
· Score: 1
Just thought I'd point out that pretty much all the benchmarks out there are using applications running in 32 bit mode. So before people start saying things like "It's not much faster than a Pentium 4 3.2GHz", when native 64bit mode apps/games start appearing (probably next year), the Athlon 64 will see an additional performace increase.
Considering the terrible performace the Itanium had running existing 32bit code, kudos to AMD for producing an architecture that will provide a gradual transition to 64 bit code.
Good god, when will people actually post about things they have a clue about? or even better, actually read the spec! OK, let's go through your points...
1. These are the same certificates that HTTPS uses, so I don't get your concept og 'overwritten', but basically every SMTP (or AMTP now) server has to have a cert. If a spammer puts 'personal' instead of 'commercial', then as soon as you find out that spammer is lying about the type of mail, you ban them - the use of certs allows this
2. You can't steal someone's cert - go a read a book about public/private key cryptography to find out why.
3. all they big spammers use their own servers - and take advantage of open relays / other servers that accept anything - if everyone is forced to use AMTP, then this is made a hell of a lot harder.
Did anyone else notice the copyright notice at the end of the video was 2001? And that the actual page is copyrighted 2002? Now come on guys, I know this is 'News for Nerds. Stuff that matters' but is a two year old project still 'news'?
Sigh. I wish the submitters (and the editors) would stop for a moment, and check out a story before it gets posted. Hey, would it be too much to ask the same of posters? Sure, everyone wants to be the first with a good story / comment, but this seems to be at the expense of any quality these days!
(Picks up walking stick while muttering something about "In my day......")
There's been a lot of talk about the 'infinite' updatedness of debian/gentoo etc, due to apt-get and ebuild. This of course means you can keep upgrading the box while it is running (no 2 hour install process) and at most a reboot for the new kernel.
However, people may have not realised that redhat have recently added a new switch to up2date:
rpm --upgrade-to-release=<release-version>
I haven't used it (and I haven't got any boxes running RH
Now RH9, plus up2date subscription (~$60) plus the new up2date could solve the "what happens at the end of RH9s lifecycle?" problem. Obviously you would have to still test all your code on the new platform etc, but this along with the other up2date options (--undo, --dry-run etc) could make life a bit easier for the folks that want to stick with the 'consumer' versions...
Forgive me if I don't feel the need to use some random unproven MTA.
I hate to tell you, but the ISP I used to work for used exim throughout, with 1000s of domains and 1000s of simultaneous dialup users.
I also know that one of the largest ISPs in the UK Freeserve use(d) Exim for all their mail. So I wouldn't say it is unproven.
In europe, traditional circuit-switched telephone networks use channelised E1s, which basically have 15 64kbit/s data channels, along with a 64kbit/s control channel, giving a 2Mbit/s channel.
Using H.323 (the main VoIP standard) you can choose from a number of compression codecs, from 32kbits upwards, although there exists a couple of codecs which sound pretty good (coparable to a average analogue phone line) at 64kbit/s, to you can make the transition without effecting you capacity.
I was involved in some trials here in the UK, and (IIRC) we were using about 90kbits, and that was _crystal clear_ - the thing you most notice is that when no-one is talking, it is actually *silent* - you don't realise it until you try VoIP howe much noise is in a normal analog call.
This is fact one of the advantages of VoIP, you can have in effect variable bitrate encoding, as if no-one is talking, then you don't have any data to encode!
Slashdot Mirror
For a human eye with excellent acuity, the maximum theoretical resolution is 50 CPD[32] (1.2 arcminute per line pair, or a 0.35 mm line pair, at 1 m).
...A resolution of 2 arcminutes per line pair, equivalent to a 1 arcminute gap in an optotype, corresponds to 20/20 (normal vision) in humans
If my math is correct then this is 60% worse than the 'excellent' eye; so the figure of 477 ppi at 12 inches is 286.2ppi; so well within the retina display's capability.
Depends if you have a licence to run the OS in question.
It's Apple's OS, they developed it, spend years and millions of $$$ making it - why shouldn't they be allowed to say what machines can and can't run it?
These arguments about "I'd buy a Mac if it had exactly X configuration, but seeing as they don't I'll just pirate it on my own system" have absolutely zero merit. Just because the developers of Windows and Linux have chosen to let you run their OS on any x86 machine, doesn't mean you automatically have the right to run any piece of software you like on your machine.
What I mean by passive detection systems is anything like an optical camera which does not need to emit anything to see something. I am not sure what technologies could be used, but while hiding is a good thing, being able to 'see' is just as important.
An optical camera relies on light coming from or reflect off an object to see it. Light only travels a matter of a few metres underwater, and to hear another vessel (i.e. SONAR) that vessel needs to be emitting some sound; which these submarines are designed to minimise.
My point is that there isn't really *a* x86 ABI. It's an application level interface, and so it is defined by the operating system and associated environment. You are correct that the Mach-O (OS X) ABI is different that the Linux/*BSD or even the Windows one, but that's purely down to the OS design, not the CPU design. Plenty of embedded systems which use x86 chips have their own ABI, with greater or lesser amounts of rules.
Note: The ABI (Application Binary Interface) isn't defined by the chip, it's defined by the Operating System. Linux generally uses the System V ABI (on x86), simply because it was easier to use a common ABI than invent your own. Keeping the Linux ABI for x86-64 similar to the x86 one makes the whole toolchain much easier to develop. There is nothing stopping you from calling functions in any way you see fit, saving and restoring no information if you want, but you'll have fun when interfacing with other pre-compiled libraries. Most of the stuff in the ABI is there for a good reason, and the optional stuff (previous stack frame) can generally be disabled with the appropriate optimisation setting in your compiler.
I see no mention of virtualisation techiques that virtualise a different architecture - such as Transitive's QuickTransit software, of Rosetta fame. They announced a version of their software the other day which virtualises a SPARC Solaris machine on x86-64 Linux, which sounds more interesting than simply pretending to be yourself :)
Note that in their test AnandTech were running the Yonah and X2 in a desktop motherboard, with a fast PCIe graphics card, desktop HDD to make a fair comparision with thier previous Dothan review - see here for tech specs.
Also note that the power consumption figures quoted are total system.so the majority of that power will be driving the rest of the PC, not the CPU. This is why the difference doesn't look very big between the Yonah and X2. However, if you could get figures for the just the CPU (which isn't very easy to do in this sort of review), I think we'd see a different story...
Note: although there are only 24 physical frames every sec, the shutter actually runs at twice this speed (i.e. each frame is displayed twice), so the shutter speed is 48fps. A shutter speed of only 24 fps, projecting on such a large arc of vision would look terrible!
Just to clarify, it's not actually that hard to get music off an iPod. Sure, iTunes won't let you copy music off it, but on a PC, it's this simple:
Voila! - All your mp3s are there - you can even play then straight off the iPod (in something like WinAMP) if you like.
Admittedly, on a Mac you have to resort to the Terminal (basically all the music files are hidden in Finder), but it's not exactly rocket science!
Well I refer back to the underground cinema screen with _no_ reception - is the doctor/ user of a medical monitor going to sue becuase their phone didn't work? If so then something is definitely wrong.
The example that everyone uses of a doctor is bogus really - if a doctor is on call then they have to be able to take that call - if a cinema puts up a notice - publicly in the lobby before you go in - saying mobiles are not permitted, then they have evey right to enforce that policy in their own cinema - if the doctor doesn't like it then they can go to another cinema.
The blocking of mobiles in non-public places such as cinemas, theatres and the like is up to the owner of the cinema etc. It's just like any other conditions of sale such as no smoking - no-one is forcing you to go to that cinema and have your phone blocked, it's just that if you do, then that's what will happen.
The nature of supply and demand wil then determine if these mesaures are sucessful or not - if people don't want to have their phone blocked in a cinema, then they will go to another. However, I know at least one person that would patronise such a cinema.
What about if the doctor went to the cinema and the local cell transmitter went down? Cell-phones have no SLA (service level agreement), so a doctor has no guarantee that he will get service in the cinema anyway.
Plus when I worked in a cinema here in the UK, we had a scren that was underground, and you couldn't get reception there _ever_!
The way I see it, if a cinema puts up a notice saying that cellphones are not allowed in the auditorium, then there's nothing wrong with them using technology to inforce it - it's no different than having the usher(s) kick people out that use them.
Thers's actually only 19 Address bits therefore it has only half as much (512K) - still perfectly reasonable...
First the PATRIOT act, and now this - is there some kind of law in the U.S. that mandates that every bill's name has to make some clever (read: daft) acronym? As a UK citizen, I'm not hugely exposed to US legislation, but the UK government's bills generally speaking don't have such overly long names, whose only purpose seems to confuse the actual purpose of the bill and give it a cool acronym...
As subject, this torrent is actually the linux kernel ver 2.6.2!
Just thought I'd point out that pretty much all the benchmarks out there are using applications running in 32 bit mode. So before people start saying things like "It's not much faster than a Pentium 4 3.2GHz", when native 64bit mode apps/games start appearing (probably next year), the Athlon 64 will see an additional performace increase.
Considering the terrible performace the Itanium had running existing 32bit code, kudos to AMD for producing an architecture that will provide a gradual transition to 64 bit code.
Good god, when will people actually post about things they have a clue about? or even better, actually read the spec! OK, let's go through your points...
1. These are the same certificates that HTTPS uses, so I don't get your concept og 'overwritten', but basically every SMTP (or AMTP now) server has to have a cert. If a spammer puts 'personal' instead of 'commercial', then as soon as you find out that spammer is lying about the type of mail, you ban them - the use of certs allows this
2. You can't steal someone's cert - go a read a book about public/private key cryptography to find out why.
3. all they big spammers use their own servers - and take advantage of open relays / other servers that accept anything - if everyone is forced to use AMTP, then this is made a hell of a lot harder.
Did anyone else notice the copyright notice at the end of the video was 2001? And that the actual page is copyrighted 2002? Now come on guys, I know this is 'News for Nerds. Stuff that matters' but is a two year old project still 'news'?
Sigh. I wish the submitters (and the editors) would stop for a moment, and check out a story before it gets posted. Hey, would it be too much to ask the same of posters? Sure, everyone wants to be the first with a good story / comment, but this seems to be at the expense of any quality these days!
(Picks up walking stick while muttering something about "In my day......")
There's been a lot of talk about the 'infinite' updatedness of debian/gentoo etc, due to apt-get and ebuild. This of course means you can keep upgrading the box while it is running (no 2 hour install process) and at most a reboot for the new kernel.
However, people may have not realised that redhat have recently added a new switch to up2date:
I haven't used it (and I haven't got any boxes running RH
Now RH9, plus up2date subscription (~$60) plus the new up2date could solve the "what happens at the end of RH9s lifecycle?" problem. Obviously you would have to still test all your code on the new platform etc, but this along with the other up2date options (--undo, --dry-run etc) could make life a bit easier for the folks that want to stick with the 'consumer' versions...
Correction - you get 32 channels on an E1, with 2 lost to signalling and control, leaving 30 usable data channels... Sorry :-)
The main VoIP standard is H.323 - Check out OpenH323, an open-source implentation of this technology.
In europe, traditional circuit-switched telephone networks use channelised E1s, which basically have 15 64kbit/s data channels, along with a 64kbit/s control channel, giving a 2Mbit/s channel.
Using H.323 (the main VoIP standard) you can choose from a number of compression codecs, from 32kbits upwards, although there exists a couple of codecs which sound pretty good (coparable to a average analogue phone line) at 64kbit/s, to you can make the transition without effecting you capacity.
I was involved in some trials here in the UK, and (IIRC) we were using about 90kbits, and that was _crystal clear_ - the thing you most notice is that when no-one is talking, it is actually *silent* - you don't realise it until you try VoIP howe much noise is in a normal analog call.
This is fact one of the advantages of VoIP, you can have in effect variable bitrate encoding, as if no-one is talking, then you don't have any data to encode!
Use the source Luke!
48 fps (showing each frame twice) is the standard for 35mm and 70mm films. As far as IMAX is concerned i'm not sure (dunno what the frame rate is).