I guess I didn't, I don't think you got mine either.:)
quite possible. but we're getting there.:)
however, i think you gave the perfect example to illustrate my point: OS X. iiac in OS X the underlying fs is a normal case sensitive unix fs, and applications handle issues like case insensitivity. (iiac)
What I'm saying is, to a degree, this is already being done at the filesystem level.
no, what you're saying is it/can/ be. that doesnt mean it's a good idea, or that there are no better ideas.
For example, installs that can run on DOS filesystems, like Zipslack. The kernel isn't specially modified in order to do that (AFAIK), but the kernel component dealing with that specfic filesystem handles the limitations and abstracts the fs from the rest of the kernel.
indeed. DOS is case insensitive by specification. what the actual detail is i dont know. it could be that filenames are all ways tolower()'ed before comparison and before writing to disk. doesnt matter. however, go read the man page and look at all the options for the msdos filesystem relating to filename lookups and charset issues. (eg code pages, 8 bit chars, etc..)
once you go start down this road, where do you stop? eg, what exactly does "case sensitive" mean? you are assuming western alphabets. what about asian characters? what about pure symbols? you end up having to put intimate knowledge of, eg, unicode (which tries to cover most of the character sets of the world) into the filesystem.
also, once that knowledge is put in the kernel, the expression of that knowledge by the kernel to applications, eg through behaviour of case handling, becomes almost set in stone.
also, your filesystem is now probably limited to character set and encoding you chose to use. What if something better comes along? you cant use it without fundamentally changing one of the building blocks of your computer. and any programming errors in kernel code can crash your machine, even trash all the data on your disks, so you really want your kernel to be as simple as possible, and you really want to keep as much complexity as possible (eg how to interpret arrays of bytes into the symbols that humans use) out of the kernel and in userspace where potential to affect reliability/integrity is lower.
like i said, a unix fs by default supports UTF-8, and any future char set + encoding that may be invented. (as long it takes care to mind its '\0's and '/'s).
Application code could handle it, though.
exactly:)
It's just a lot of places to change and you would want to be consistent.
well, consistency of applications is by definition just not a kernel problem. And isnt OS X consistent?
I suppose there are larger UI issues to worry about, I was mainly wanting to counter the "silly newbies, Linux is for real hax0rs" chorus.
urg.. give me open-minded unix newbies over those any day.:)
Thanks for comming up with a real answer Oh, and AFAIK: By default OSX uses HFS+ which is the same filesystem as OS9 and before. It also supports UFS(?), a filesystem from Apple's A/UX, which is a traditional unix fs.
indeed.
so what is the default filesystem on an OS X install? and if UFS is used, are the user applications case sensitive or not? i'd be very curious to find out as to how OS X deals with this.
the point is that case insensitivity can be done just as well by user applications as by the kernel. (with the benefits to the kernel in overhead and not getting involved in policy that i detailed before). Hence it should not be done by the kernel.
Eg: the GNOME file dialogue - that could easily do case sensitivity checks. Nautilus could be made case insensitive. The only time the novice user you speak of will notice, on this as yet non-existant case insensitive distro, that the underlying filesystem treats filenames as byte arrays and no more is if the novice user opens up a terminal and uses regular unix commands.
Also, OS X: i'm not 100% sure, but i suspect OS X is the perfect example of what i'm talking about. Ie a traditional unix filesystem, with case insensivity, etc. done by user applications. AFAIK (and i could be wrong) if you open a terminal on OS X you will find the underlying FS is a traditional case-sensitive unix fs.
Ie - it's all done by application code.. not kernel code. (least it should be).
hmm, well it's not that "pure" unicode is incompatible with unix kernel APIs, it's more that pure unicode is incompatible with the vast majority of C APIs that handle strings (of which parts of the kernel API might be fall under).
however, guess what, "they" thought of this problem and solved it. Hence (eventually) UTF-8 - which encodes the unicode character set to ASCII compatible bytes, hence it can be used with kernel APIs such as filenames.
man ascii man unicode man utf-8
so again, unix has supported unicode since before it was even invented.:)
and again, if in the future some new, more expansive character set and encoding standards are brought in, unix will support those too, as long the encoding makes sure to escape any byte bounded 0x00's and 0x2f's that might occur in the character set.
PS: what's an 8-bit zero terminated string exactly?:) (just kidding - know what you mean, but it's perhaps a strange way of putting it).
yes there is a good reason. and it is not about "removing" case-sensitivity, it's about adding it.
The basic issue is that Unix filesystems at the kernel level do not interpret filesystems in/any/ way what so ever. The only restrictions on Unix filesystem names is that no byte within a name may equal '\0' or '/'. You can put whatever characters or bits you want in a filename as long no byte equals ASCII \0 or/.
This means no "tolower()" or case comparison overhead in the kernel. No complicated (and perhaps non-obvious) policy in the kernel.
It also means filename schemes are easily extensible in userspace. Eg, Unix filesystems support Unicode, UTF-8, ISO8559-[0-9][0-9], and whatever other encoding system you want provided you respect '\0' and '/'. In fact Unix supported Unicode, UTF-8, etc.. almost from day one (ie 1970), literally/before/ these 'beyond ASCII' schemes were even invented. Unix filesystems also support many many other future encoding schemes that have not been invented yet.:)
Basically, tolower() / case comparison can be easily done in userspace - hence that is the best place for it. Now, of course, userspace might not always agree on policy or how to implement it, but that is not a kernel problem.
Case sensitivity is a matter of taste, and as such it's best not done in the kernel (where it will be set in stone forever). That's actually a general Unix design principle "policy should be implemented in userspace" - and it's actually a very good design principle..
now let's see how many slashdotters fail to realise it..
if you have a habit of changing lanes without checking your mirrors and without looking over your shoulder to check the blind spot and instead you just assume you can, then you are quite frankly a danger to other road users, be they motorcyclists or not, and you should not be on the road - you are going to cause a major accident someday.
if you do check your mirrors, look to the blind spot and indicate before changing lanes then there's no problem.
Do the math, a bike filtering through traffic at a 20mph differential (and 20mph diff is quite fast. 10mph diff is far more reasonable) will spend at least 10 seconds covering the last 100m of ground between the 2 of you. So if you have 100m of visibility behind you (almost guaranteed on motorways/dual carriageways) the bike will have been visible in your mirrors for at least 10 seconds.
With 200m, 20mph diff: 22seconds With 100m, 15mph diff: 15s With 200m, 16mph diff: 30s With 100m / 10mph diff: 22s With 200m / 10mph diff: 45s
Now 20mph diff is nearly bordering on reckless (depending on the conditions - eg 100m / 20mph -> dangerous). So lets assume 15mph.
So between 15mph,100m and 10mph,200m its safe to assume that a biker filtering through traffic will have been visible in your mirrors for at least 15seconds and perhaps anything up to 45 seconds.
Needless to say, you should be checking your mirrors at least every 15 seconds (if not more). So you should see the biker.
Also, the motorcyclist can make use of acceleration to minimise exposure to danger. (which to the car driver seems like a bike speeding past - but its actually a crucial motorcycle safety technique when used in low density traffic).
In the last resort, if you really are, as your post almost implies, the kind of feckless driver who does not check his mirrors regularly and, worse, changes lane without checking mirrors - hopefully i will have spotted you in advance. If i dont, and you cut me up cause of your idiocy, then i should be able to avoid you. (motorcycling rule: always have a plan A, a plan B and an escape route from other traffic - including pedestrians and cyclists.). Rest assured that, if i have the time and opportunity, at the next traffic lights i will politely inform you of your stupidity.:) Hopefully you'll be more careful in the future.
but, anyway, i hope you're/not/ that kind of driver.:)
And i never said traffic jam - i said "stuck in traffic". (and on a bike any kind of car traffic is 'stuck in traffic')
Also, like i said, it is perfectly safe as long the speed differential isnt too great, eg no more than 20mph - depending on the density of the traffic. If the biker is any kind of decent rider, then as he passes you he's already spent several seconds observing how you drive as he approached you, and as he passes by you he's keeping an eye on any or all of your steering-wheel, bonnet or front wheels (depending on which is most visible to him) looking for any indication of an imminent change in direction.
it's up to the bike to make a safe pass, and as long as a car driver observes the minimum of safety precautions (ie look over shoulder and check mirrors before changing lane) there is no problem.
the only danger is car drivers who just cant be arsed to check the lane is clear before changing lane. and even here a good biker should easily be able to take evasive action.
Firstly, i presume you mean "in between lanes" not "in the middle lane".
Secondly, as both a motorcyclist and a car driver: getting passed by motorbikes in traffic - do you think the motorcyclist is going to stay stuck in lane behind cars? Course not. Also, in quite a few countries this is legal - its called filtering. (as long it doesnt border on dangerous/reckless driving - ie motorcyclists should keep the speed differential down to a max of 20mph differential).
it's a big part of the attraction of having a motor bike for commuting, the fact that you/never/ get stuck in traffic.
Hard shoulder at 100MPH is obviously dumb. But hard shoulder at a safe speed differential is fine if the cars are going quite slow (eg sub 20mph). (whether its technically legal or not is another question - but at least a motorbike is not going to block the hard shoulder).
But what a petty post. Just cause you get peeved while sitting in traffic jams you have to begrudge those who are on bikes and dont get stuck. maybe you need to get a bike.:)
Re:Look to your Sparc for the warning
on
AMD's 64-Bit Chip
·
· Score: 2
Or a DEC/Compaq Alpha workstation, or a Silicon Graphics MIPS Workstation.. And arent HPs PA-RISC machines 64bit too?
But the funniest of all:
A lot of WinCE pocketpc type things are using 64bit capable embedded cpu's. (a lot of the embedded MIPS clone CPUs used in handhelds can do 64 bit, eg NEC VR series).
aye, that's a nice picture too. i had found a very small version of it, but not a decent sized one. there should be quite a few more pictures of his jump, but i cant find any online.:(
My preference in the pictures though is for the one that appeared on the Life cover - an expanse of cloud mass, that looks like it's photographed from orbit/high up - and a wee speck of a man in a space suit sticking one leg out to control his fall. You just get an amazing sense of how extreme his jump was, as the background and the man look more like the images we've seen of astronauts on EVA than of a man parachuting to earth. The only clue: no umbilical.
Though the picture you posted a link to is technically more interesting as you get a much better view of his kit, i like the cover picture better for it's sense of perspective.
i'd somehow formed the impression that beer was a specific type of brewed alcoholic beverage. eg, the Belgians and Germans had laws regarding what was 'bier'. perhaps the english meaning of beer doesnt have these connotations.
AMD Hammer/Opteron is completely IA32 (ie normal 32bit x86) compatible - all IA32 OSes boot on it, it has a standard IA32 BIOS, applications will run fine on it. If you run a x86-64 OS, then you will be able to run both 32bit and 64bit x86-64 software (side by side).
Ie x86-64 is:
- IA32 (8086 mode et al too - i/guess/) - standard IA32 BIOS - additional x86-64 mode
Apparently 32-bit Linux and Windows booted almost first time on early silicon, and they've had absolutely no 32bit compatibility problems - it all works. then it took just a week for AMD to get linux to boot into x86-64 mode (iirc from the talk linked below).
IA64 / Itanium on the other hand is a completely new architecture:
- completely different instruction set - completely different ABI - new weird "look it does everything" BIOS (EFI) - IA32 is/emulated/ in silicon and hence slow
There's a good talk by an AMD engineer on the AMD Hammer arch. given at the recent kernel summit at:
Used to set different policy (uncacheable, write-back, write-combing) to address ranges. Eg, for address ranges that correspond to PCI addresses (ie memory mapped IO addresses), by setting these ranges to write-combining the CPU will try to gather writes up into big writes to make most efficient use of IO bus bandwidth. (ie get higher MB/s out of your AGP or PCI - important for graphics).
Perhaps it's time to implement flap-dampening in the financial markets?
put an arbitrary lag time in between buy/sell orders. Scale this lag time according to stability of the market. Put upper and lower bounds on the lag factor. eg minimum of 1 week, max of 3 months.
In very stable times, you'd have, say, a week between order and execution, if something caused the market to become volatile, lag factor would increase accordingly, up to say, 3 or 4 months. In times of imbalance (selling > than buying), the lag factor would increase and dampen it / slow it down, and in times of stability (selling ~= buying) the lag factor would be at a minimum and more responsive. Volume would not be affected - as long as the market stays reasonably stable.
This would force people to make stock decisions based on/long-term/ factors, cause short-term wouldnt be available and mid-term (eg 6 months) would have little value, because the possibility would be there that in the mid-term when they want to sell/buy lag time might be one or two months and they'd be caught out.
So the market be dampened from volatility. Investors would need to play it on a long-term basis, which would need neccessitate quite 'frank' accounting practices - which would be lobbied for and put in place.
Tru64 is nee Digital Unix nee OSF/1 - a project that came about when DEC, HP and IBM came together to found The Open Software Foundation (OSF) to develop "open" unix (they felt threatened by Sun i think). The OSF released OSF/1, a System V R2 based Unix, which was adopted by DEC as it's new Unix to replace RISC Ultrix.
well, aboot running yer games an' lightwave oan linux, i dinnae really ken aboot lightwave, whit diz it dae? I ken ILM (the big CGI house) er usin' linux fer their animation, thur's a storie on linuxtodae aboot them switchin oar fae SGI to linux.
games, well i reckon you wannae check oot Wine-X - wads of folk been havin luck gettin their games running oan linux wae it. It might e'en run yer lightwave tae.
Slashdot Mirror
I guess I didn't, I don't think you got mine either. :)
:)
/can/ be. that doesnt mean it's a good idea, or that there are no better ideas.
:)
:)
quite possible. but we're getting there.
however, i think you gave the perfect example to illustrate my point: OS X. iiac in OS X the underlying fs is a normal case sensitive unix fs, and applications handle issues like case insensitivity. (iiac)
What I'm saying is, to a degree, this is already being done at the filesystem level.
no, what you're saying is it
For example, installs that can run on DOS filesystems, like Zipslack. The kernel isn't specially modified in order to do that (AFAIK), but the kernel component dealing with that specfic filesystem handles the limitations and abstracts the fs from the rest of the kernel.
indeed. DOS is case insensitive by specification. what the actual detail is i dont know. it could be that filenames are all ways tolower()'ed before comparison and before writing to disk. doesnt matter. however, go read the man page and look at all the options for the msdos filesystem relating to filename lookups and charset issues. (eg code pages, 8 bit chars, etc..)
once you go start down this road, where do you stop? eg, what exactly does "case sensitive" mean? you are assuming western alphabets. what about asian characters? what about pure symbols? you end up having to put intimate knowledge of, eg, unicode (which tries to cover most of the character sets of the world) into the filesystem.
also, once that knowledge is put in the kernel, the expression of that knowledge by the kernel to applications, eg through behaviour of case handling, becomes almost set in stone.
also, your filesystem is now probably limited to character set and encoding you chose to use. What if something better comes along? you cant use it without fundamentally changing one of the building blocks of your computer. and any programming errors in kernel code can crash your machine, even trash all the data on your disks, so you really want your kernel to be as simple as possible, and you really want to keep as much complexity as possible (eg how to interpret arrays of bytes into the symbols that humans use) out of the kernel and in userspace where potential to affect reliability/integrity is lower.
like i said, a unix fs by default supports UTF-8, and any future char set + encoding that may be invented. (as long it takes care to mind its '\0's and '/'s).
Application code could handle it, though.
exactly
It's just a lot of places to change and you would want to be consistent.
well, consistency of applications is by definition just not a kernel problem. And isnt OS X consistent?
I suppose there are larger UI issues to worry about, I was mainly wanting to counter the "silly newbies, Linux is for real hax0rs" chorus.
urg.. give me open-minded unix newbies over those any day.
Thanks for comming up with a real answer Oh, and AFAIK: By default OSX uses HFS+ which is the same filesystem as OS9 and before. It also supports UFS(?), a filesystem from Apple's A/UX, which is a traditional unix fs.
indeed.
so what is the default filesystem on an OS X install? and if UFS is used, are the user applications case sensitive or not? i'd be very curious to find out as to how OS X deals with this.
sigh.. you didnt get the point did you? :)
the point is that case insensitivity can be done just as well by user applications as by the kernel. (with the benefits to the kernel in overhead and not getting involved in policy that i detailed before). Hence it should not be done by the kernel.
Eg: the GNOME file dialogue - that could easily do case sensitivity checks. Nautilus could be made case insensitive. The only time the novice user you speak of will notice, on this as yet non-existant case insensitive distro, that the underlying filesystem treats filenames as byte arrays and no more is if the novice user opens up a terminal and uses regular unix commands.
Also, OS X: i'm not 100% sure, but i suspect OS X is the perfect example of what i'm talking about. Ie a traditional unix filesystem, with case insensivity, etc. done by user applications. AFAIK (and i could be wrong) if you open a terminal on OS X you will find the underlying FS is a traditional case-sensitive unix fs.
Ie - it's all done by application code.. not kernel code. (least it should be).
hmm, well it's not that "pure" unicode is incompatible with unix kernel APIs, it's more that pure unicode is incompatible with the vast majority of C APIs that handle strings (of which parts of the kernel API might be fall under).
:)
:) (just kidding - know what you mean, but it's perhaps a strange way of putting it).
however, guess what, "they" thought of this problem and solved it. Hence (eventually) UTF-8 - which encodes the unicode character set to ASCII compatible bytes, hence it can be used with kernel APIs such as filenames.
man ascii
man unicode
man utf-8
so again, unix has supported unicode since before it was even invented.
and again, if in the future some new, more expansive character set and encoding standards are brought in, unix will support those too, as long the encoding makes sure to escape any byte bounded 0x00's and 0x2f's that might occur in the character set.
PS: what's an 8-bit zero terminated string exactly?
no idea. you have examples of those unicode chars?
anyway - it's not the kernel's problem, that's the precise point. the encoding is a userspace problem.
also, those chars can not be used in URIs either. So i suspect one answer is to deal with them in the same way as for URIs.
--paulj
yes there is a good reason. and it is not about "removing" case-sensitivity, it's about adding it.
/any/ way what so ever. The only restrictions on Unix filesystem names is that no byte within a name may equal '\0' or '/'. You can put whatever characters or bits you want in a filename as long no byte equals ASCII \0 or /.
/before/ these 'beyond ASCII' schemes were even invented. Unix filesystems also support many many other future encoding schemes that have not been invented yet. :)
The basic issue is that Unix filesystems at the kernel level do not interpret filesystems in
This means no "tolower()" or case comparison overhead in the kernel. No complicated (and perhaps non-obvious) policy in the kernel.
It also means filename schemes are easily extensible in userspace. Eg, Unix filesystems support Unicode, UTF-8, ISO8559-[0-9][0-9], and whatever other encoding system you want provided you respect '\0' and '/'. In fact Unix supported Unicode, UTF-8, etc.. almost from day one (ie 1970), literally
Basically, tolower() / case comparison can be easily done in userspace - hence that is the best place for it. Now, of course, userspace might not always agree on policy or how to implement it, but that is not a kernel problem.
Case sensitivity is a matter of taste, and as such it's best not done in the kernel (where it will be set in stone forever). That's actually a general Unix design principle "policy should be implemented in userspace" - and it's actually a very good design principle..
now let's see how many slashdotters fail to realise it..
someone mod this up.
dessicant is essential on a yacht if you want anything to last any amount time, be it electronics kit, fabric, victuals, etc..
if you have a habit of changing lanes without checking your mirrors and without looking over your shoulder to check the blind spot and instead you just assume you can, then you are quite frankly a danger to other road users, be they motorcyclists or not, and you should not be on the road - you are going to cause a major accident someday.
:) Hopefully you'll be more careful in the future.
/not/ that kind of driver. :)
if you do check your mirrors, look to the blind spot and indicate before changing lanes then there's no problem.
Do the math, a bike filtering through traffic at a 20mph differential (and 20mph diff is quite fast. 10mph diff is far more reasonable) will spend at least 10 seconds covering the last 100m of ground between the 2 of you. So if you have 100m of visibility behind you (almost guaranteed on motorways/dual carriageways) the bike will have been visible in your mirrors for at least 10 seconds.
With 200m, 20mph diff: 22seconds
With 100m, 15mph diff: 15s
With 200m, 16mph diff: 30s
With 100m / 10mph diff: 22s
With 200m / 10mph diff: 45s
Now 20mph diff is nearly bordering on reckless (depending on the conditions - eg 100m / 20mph -> dangerous). So lets assume 15mph.
So between 15mph,100m and 10mph,200m its safe to assume that a biker filtering through traffic will have been visible in your mirrors for at least 15seconds and perhaps anything up to 45 seconds.
Needless to say, you should be checking your mirrors at least every 15 seconds (if not more). So you should see the biker.
Also, the motorcyclist can make use of acceleration to minimise exposure to danger. (which to the car driver seems like a bike speeding past - but its actually a crucial motorcycle safety technique when used in low density traffic).
In the last resort, if you really are, as your post almost implies, the kind of feckless driver who does not check his mirrors regularly and, worse, changes lane without checking mirrors - hopefully i will have spotted you in advance. If i dont, and you cut me up cause of your idiocy, then i should be able to avoid you. (motorcycling rule: always have a plan A, a plan B and an escape route from other traffic - including pedestrians and cyclists.). Rest assured that, if i have the time and opportunity, at the next traffic lights i will politely inform you of your stupidity.
but, anyway, i hope you're
And i never said traffic jam - i said "stuck in traffic". (and on a bike any kind of car traffic is 'stuck in traffic')
Also, like i said, it is perfectly safe as long the speed differential isnt too great, eg no more than 20mph - depending on the density of the traffic. If the biker is any kind of decent rider, then as he passes you he's already spent several seconds observing how you drive as he approached you, and as he passes by you he's keeping an eye on any or all of your steering-wheel, bonnet or front wheels (depending on which is most visible to him) looking for any indication of an imminent change in direction.
it's up to the bike to make a safe pass, and as long as a car driver observes the minimum of safety precautions (ie look over shoulder and check mirrors before changing lane) there is no problem.
the only danger is car drivers who just cant be arsed to check the lane is clear before changing lane. and even here a good biker should easily be able to take evasive action.
anyway.. stop spreading FUD about bikes.
--paulj
Firstly, i presume you mean "in between lanes" not "in the middle lane".
/never/ get stuck in traffic.
:)
Secondly, as both a motorcyclist and a car driver: getting passed by motorbikes in traffic - do you think the motorcyclist is going to stay stuck in lane behind cars? Course not. Also, in quite a few countries this is legal - its called filtering. (as long it doesnt border on dangerous/reckless driving - ie motorcyclists should keep the speed differential down to a max of 20mph differential).
it's a big part of the attraction of having a motor bike for commuting, the fact that you
Hard shoulder at 100MPH is obviously dumb. But hard shoulder at a safe speed differential is fine if the cars are going quite slow (eg sub 20mph). (whether its technically legal or not is another question - but at least a motorbike is not going to block the hard shoulder).
But what a petty post. Just cause you get peeved while sitting in traffic jams you have to begrudge those who are on bikes and dont get stuck. maybe you need to get a bike.
--paulj
NB: it's spelt "Worcestershire".
Or a DEC/Compaq Alpha workstation, or a Silicon Graphics MIPS Workstation.. And arent HPs PA-RISC machines 64bit too?
But the funniest of all:
A lot of WinCE pocketpc type things are using 64bit capable embedded cpu's. (a lot of the embedded MIPS clone CPUs used in handhelds can do 64 bit, eg NEC VR series).
aye, that's a nice picture too. i had found a very small version of it, but not a decent sized one. there should be quite a few more pictures of his jump, but i cant find any online. :(
My preference in the pictures though is for the one that appeared on the Life cover - an expanse of cloud mass, that looks like it's photographed from orbit/high up - and a wee speck of a man in a space suit sticking one leg out to control his fall. You just get an amazing sense of how extreme his jump was, as the background and the man look more like the images we've seen of astronauts on EVA than of a man parachuting to earth. The only clue: no umbilical.
Though the picture you posted a link to is technically more interesting as you get a much better view of his kit, i like the cover picture better for it's sense of perspective.
http://www2.tsixroads.com/Corinth_MLSANDY/jk004
including an amazing shot of him taken from the gondola from which he jumped:
http://www2.tsixroads.com/Corinth_MLSANDY/corin
indeed, which is why stout is not beer. :)
least that was my way of thinking. anyway.. give me a guinness anyday. (the smell round St. James Gate in dublin is lovely.)
--paulj
well consider me educated.
i'd somehow formed the impression that beer was a specific type of brewed alcoholic beverage. eg, the Belgians and Germans had laws regarding what was 'bier'. perhaps the english meaning of beer doesnt have these connotations.
anyway.
guiness isnt beer - it's stout.
good news:
Hammer in 64bit mode:
- double the number of registers.
- linux ABI will use the SSE registers for fp (apart from double double), AMD are strongly encouraging people not to use x87 for FP in 64bit mode.
Itanium is /not/ RISC. Go read up on VLIW (Very Long Instruction Word), which is what Itanium is. (as is the Transmeta Crusoe silicon).
AMD Hammer/Opteron is completely IA32 (ie normal 32bit x86) compatible - all IA32 OSes boot on it, it has a standard IA32 BIOS, applications will run fine on it. If you run a x86-64 OS, then you will be able to run both 32bit and 64bit x86-64 software (side by side).
/guess/)
/emulated/ in silicon and hence slow
c le.pl?sid=02/06/26/0116225
Ie x86-64 is:
- IA32 (8086 mode et al too - i
- standard IA32 BIOS
- additional x86-64 mode
Apparently 32-bit Linux and Windows booted almost first time on early silicon, and they've had absolutely no 32bit compatibility problems - it all works. then it took just a week for AMD to get linux to boot into x86-64 mode (iirc from the talk linked below).
IA64 / Itanium on the other hand is a completely new architecture:
- completely different instruction set
- completely different ABI
- new weird "look it does everything" BIOS (EFI)
- IA32 is
There's a good talk by an AMD engineer on the AMD Hammer arch. given at the recent kernel summit at:
http://ksmp3rep.sf.net/KSMP3s/amd64.mp3
found amongst other kernel summit talks at:
http://linuxkernel.foundries.sourceforge.net/arti
MTRR == Memory Type Range Register
/proc/mtrr.
Used to set different policy (uncacheable, write-back, write-combing) to address ranges. Eg, for address ranges that correspond to PCI addresses (ie memory mapped IO addresses), by setting these ranges to write-combining the CPU will try to gather writes up into big writes to make most efficient use of IO bus bandwidth. (ie get higher MB/s out of your AGP or PCI - important for graphics).
see linux/Documentation/mtrr.txt and
Perhaps it's time to implement flap-dampening in the financial markets?
/long-term/ factors, cause short-term wouldnt be available and mid-term (eg 6 months) would have little value, because the possibility would be there that in the mid-term when they want to sell/buy lag time might be one or two months and they'd be caught out.
put an arbitrary lag time in between buy/sell orders. Scale this lag time according to stability of the market. Put upper and lower bounds on the lag factor. eg minimum of 1 week, max of 3 months.
In very stable times, you'd have, say, a week between order and execution, if something caused the market to become volatile, lag factor would increase accordingly, up to say, 3 or 4 months. In times of imbalance (selling > than buying), the lag factor would increase and dampen it / slow it down, and in times of stability (selling ~= buying) the lag factor would be at a minimum and more responsive. Volume would not be affected - as long as the market stays reasonably stable.
This would force people to make stock decisions based on
So the market be dampened from volatility. Investors would need to play it on a long-term basis, which would need neccessitate quite 'frank' accounting practices - which would be lobbied for and put in place.
anyway..
Ultrix was a BSD derived Unix.
Tru64 is nee Digital Unix nee OSF/1 - a project that came about when DEC, HP and IBM came together to found The Open Software Foundation (OSF) to develop "open" unix (they felt threatened by Sun i think). The OSF released OSF/1, a System V R2 based Unix, which was adopted by DEC as it's new Unix to replace RISC Ultrix.
not if the honda were to be made to carry the same load as the caterpillar.
doh.. WineX is of course at:
http://www.transgaming.com/
"cannae run", you must be fae scotland.. :)
well, aboot running yer games an' lightwave oan linux, i dinnae really ken aboot lightwave, whit diz it dae? I ken ILM (the big CGI house) er usin' linux fer their animation, thur's a storie on linuxtodae aboot them switchin oar fae SGI to linux.
games, well i reckon you wannae check oot Wine-X - wads of folk been havin luck gettin their games running oan linux wae it. It might e'en run yer lightwave tae.
Wine-X is at http://www.blizzard.com/