Although I think MySQL 4.0 has added transactions anyway (I may be wrong,) you may as well just have written: (if he doesn't care if his data is correct.)
I don't understand why people be-little transaction support. It is possibly the single biggest reason to use PG over MySQL. You can throw more hardware at a slow database, but you can do nothing for corrupt data (not that PG is slow!)
Process context switches are of the order of microseconds (sub microsecond.)
Disk IO is of the order of milliseconds!
Context switches are several orders of magnitude quicker than disk IO. If data can be stored in RAM, that is the biggest gain you can get (given the same database design.)
What the Bamboo guys may be on about is not transporting large result sets over the wire between the client and the server, which can be really slow in relative terms. Don't know what the bamboo project is, however, so that last bit is a stab in the dark.
But this protocol extension, I like. Somebody please give *technical* reasons why it is not good.
How about: - An extra speculative packet is required to see if this 'feature' is supported. - Are there security implications? If this is an OS level feature, then an application might not know whether a new request is from a new client or from an old connection. - If persistance is required, then implement it on top of the existing protocol, just like HTTP/1.1 already does! - New API/socket options required to access this functionality. Can't be nice. Winsock is bad enough without more crap.
Re:Reality vs. Silly stereotypes
on
239 MPG Car
·
· Score: 1
The US voted against it not because we don't particularly care about the environment but because it basically amounted to economic sanctions against the US.
That would wash if it wasn't for the sanctions the US (threaten or otherwise) impart on nations on much smaller issues. One example is the threatened sanctions against Ukraine over production of untraceable CD-Rs!
Actually, despite Bill "Teflon Shoulders" Gates saying otherwise, it was MS-DOS's fault that the world stayed 16-bit (and hence 640k) for so long.
Had DOS provided a proper segment handling interface, and provided proper device drivers so that people didn't have to go to the metal, software written on a lowly 8086 could have run fine in 286 protected mode, and super in 386 protected mode.
I would class the long running slave trade, the genocide of the native people, the land grabs, the racism, the continuing poverty among the poorer people of the US as plenty justification for the comment.
It's all very well you Americans bleating on about democracy and your constitution, while all the time, the US is based on all of the above human tragedies.
And do you know (or care!) how many military dictators the US put in place and/or supported? For example, a good friend of mine was tortured in prison in a state that had a US sponsored military coup, because she was a member of the communist party.
Don't get me wrong, I have no love for our (British) monarchy, and have nothing against Americans for the most part, but this high horse attitude really pisses me off.
Monarchies represent a past littered with cruelity, poverty, slavery, oppresion, injustice
A bit like the modern US of A then...
The French only helped you lot to piss the English off. Not some idealistic crusade.
Oh, and the French went on an imperialistic rampage throughout Europe after toppling the monarchy, with associated cruelity, poverty, slavery, oppresion and injustice.
One reason, stated in the article, is that the UltraSPARC IIe uses only 13W of power for the CPU and intergrated memory controller and PCI controller. Apart from the main CPU, then, there'll be no chips requiring heat sinks, and very little heat to disperse. Less heat means generally more reliable if any other cooling fails (like A/C.)
SCSI handles this with 'disconnects'. After the read command is sent, the controller disconnects from the bus. When the drive has read the data into it's buffers, it will send the data to the controller in a seperate transaction.
In the meantime, the bus is essentially idle, so other activity can occur.
Unlike ATA, SCSI is more like a packet switching bus, with multiple masters.
I have also wondered why more people aren't using the memory bus for peripherals....Seriously, the PCI buss can only offer so much (132 MB/S) which is certainly going to be a problem with anything faster than gigabit ethernet
Because the memory bus is a memory bus, and NOT a peripheral bus! Peripheral busses have things like interrupts, address space configuration, buffering, bridging, hot-plugging, and long-term stability that memory busses are simply not designed for.
How would you like it if you couldn't use the latest whizz bang 8.4GB/s memory technology because some peripheral you bought a year earlier needs to be on a 4.8GB/s memory interface?
Anyway, PCI v2.2 (?) offers 512MB/s in 64 bit 66MHz mode. And then there's PCI-X...
And show me a game that is PCI/AGP bandwidth limited once textures are uploaded to the GXF card anyway. Memory is cheap, use it...
Meanwhile, modern memory busses are upwards of 4.8Gb/s. Imagine multiple machines strung together with that kind of bandwidth between them!
Unfortunately, those pesky laws of physics (like the speed of light) come in and put paid to schemes like this. While it may be possible to get that bandwidth between machines, the latency becomes a problem. Certainly not feasable as a memory bus.
Were the majority of telephone systems still run by human operators as late as the late 60's to early 70's
No. I'm not sure about timescales, but in between human operators and electronic routing, there were mechanical based exchanges.
Basically, the old pulse dialing system would mechanically rotate a selector every pulse, then move to the next selector with each digit. The result was that routes between phones was selected machanically based on the pulsed phone number. My guess is that mechanical exchanges came in in the 1920s or 1930s.
Not sure how tone dialing came in. Probably the beginnings of elctronic exchanges. My guess here is 1950s or 1960s.
BTW, the actual exchanges are often MANAGED by UNIX systems, but don't actually run UNIX systems. The hardware itself is probably some custom embedded platform.
Finally, take the above with a grain of salt. I'm not a communications historian.
My Tekram DC-3903UW (Symbios 53c1010 based) uses is a 64 bit card (I think it can do 64x66MHz)
Thanks to the wonders of PCI, however, it works fine in my current 32x33 PCI slots.
Can't wait to get it onto one of these boards, as I have a couple of seagate cheatas striped on this baby, and I think PCI may be the performance bottleneck!
I've found that Solaris tends to support good quality hardware. No, you can't run a crap $5 no-name network card but you can run a nice Intel or 3com. Consequently if you build up a system to run Solaris, you are pretty much forced into building a good one. No bad thing IMHO.
Good quality? Branded, maybe, but price is no assurence of quality. Doesn't the Linux drivers at least have no end of hacks to get round bugs and/or design restrictions, certainly in the Intel based network cards. Try using an Intel network card with the default Windows NT drivers. Doesn't work, 'cos the hardware is broken.
My rtl8139 based £10 noname card has given me no problems. It certainly has some hacks in the drivers to work round a few problems, but show me hardware which doesn't.
I suppose Adaptec SCSI chips are so much better than Advansys or Symbios chipsets as well.
I find that 3Com, Adaptec and Intel are the IBMs of their respective markets. "You never get fired for buying..."
The moral of the story, statistics need to be taken with a grain of salt.
Statements like:
Garvin said. "Java usage is even stronger outside North America, with almost 60 percent of developers expecting to spend some part of their programming time using Java."
Is that in their spare time, at work, what? How much real work will be done with Java as opposed to C/C++?
Intel had promised to supply IBM their processor, and signed AMD as their 2nd tier contractor to supply processors to IBM (boy, I'm sure some Intel execs are feeling really sorry for this now)..
Probably not. Without the PC deal, Intel may not have been the powerhouses they are today.
Except that several OSes were available for the PC, including CP/M and the USCD p-System, and later Xenix.
DOS wasn't huge, and could have been reverse engineered as easily as the BIOS. It was just a functional clone of CP/M, done in about 4 man months at Seattle Computer Products from whome MS bought the rights.
Of course not, it's not like the XP kernel was origionally developed on a MIPS based machine, now is it.
The NT kernel was designed to be portable from the outset, and has run on x86, MIPS, Alpha and PPC. Nothing ties the kernel to x86 other than market forces.
Now, as someone else commented about CDs and DVDs, YES, PLEASE, QUIET THESE HORRIBLE CONTRAPTIONS. My CD on my work computer has a cache that's just big enough to allow the drive to spin down for about 1/2 a second during a big transfer. Then it spins back up and transfers more. It's loud, it's annoying, and it turns this 40 some odd X CD Rom to about 10X.
Thats where caddy based CDROMs come in handy. My Plextor 32 speed drive can barely be heard. A great drive (though it isn't entirely agreeing with my new Muse album:( My guess is that is the CD though)
The drawback is that the larger number of instructions required to complete a given task is likely to take up a larger amount of space in RAM and on disk.
On the other side of the coin, most RISC chips also have more general purpose registers, and so can dispense with much of the register/memory shuffling that x86 typically has to do.
Just getting rid of some memory accesses, as well as removing redundant instructions, also speeds up execution as register/resgister operations are MUCH faster than even cached memeory accesses.
Slashdot Mirror
That agreement went the way of the dodo in 1997, I think.
The agreement was that SCO would maintain XENIX compatibility in UNIX in return for M$ not to enter the UNIX market.
In the mid/late 90's that agreement was dissolved at the behest of SCO, as noone wanted XENIX compatibility anymore.
(if he don't need transactions, for exemple.)
Although I think MySQL 4.0 has added transactions anyway (I may be wrong,) you may as well just have written:
(if he doesn't care if his data is correct.)
I don't understand why people be-little transaction support. It is possibly the single biggest reason to use PG over MySQL. You can throw more hardware at a slow database, but you can do nothing for corrupt data (not that PG is slow!)
the D in the DMCA stands for Digital.. and opening the lid is digital, how ?
Lids are in one of two discrete states, open or closed. Pretty digital, if you ask me.
Process context switches are of the order of microseconds (sub microsecond.)
Disk IO is of the order of milliseconds!
Context switches are several orders of magnitude quicker than disk IO. If data can be stored in RAM, that is the biggest gain you can get (given the same database design.)
What the Bamboo guys may be on about is not transporting large result sets over the wire between the client and the server, which can be really slow in relative terms. Don't know what the bamboo project is, however, so that last bit is a stab in the dark.
But this protocol extension, I like. Somebody please give *technical* reasons why it is not good.
How about:
- An extra speculative packet is required to see if this 'feature' is supported.
- Are there security implications? If this is an OS level feature, then an application might not know whether a new request is from a new client or from an old connection.
- If persistance is required, then implement it on top of the existing protocol, just like HTTP/1.1 already does!
- New API/socket options required to access this functionality. Can't be nice. Winsock is bad enough without more crap.
The US voted against it not because we don't particularly care about the environment but because it basically amounted to economic sanctions against the US.
That would wash if it wasn't for the sanctions the US (threaten or otherwise) impart on nations on much smaller issues. One example is the threatened sanctions against Ukraine over production of untraceable CD-Rs!
I won't mention steel tariffs, Cuba et al, etc.
Windows does not use a microkernel!
Actually, despite Bill "Teflon Shoulders" Gates saying otherwise, it was MS-DOS's fault that the world stayed 16-bit (and hence 640k) for so long.
Had DOS provided a proper segment handling interface, and provided proper device drivers so that people didn't have to go to the metal, software written on a lowly 8086 could have run fine in 286 protected mode, and super in 386 protected mode.
IBM have made a HUGE amount of money from the PC. They only really lost control when they started back down the proprietry route (PS/2, MCA.)
If IBM hadn't done the PC when they did, it was only a matter of time before someone else did, and they'd have made no money.
> A bit like the modern US of A then
A vapid swipe with no justification.
I would class the long running slave trade, the genocide of the native people, the land grabs, the racism, the continuing poverty among the poorer people of the US as plenty justification for the comment.
It's all very well you Americans bleating on about democracy and your constitution, while all the time, the US is based on all of the above human tragedies.
And do you know (or care!) how many military dictators the US put in place and/or supported? For example, a good friend of mine was tortured in prison in a state that had a US sponsored military coup, because she was a member of the communist party.
Don't get me wrong, I have no love for our (British) monarchy, and have nothing against Americans for the most part, but this high horse attitude really pisses me off.
Monarchies represent a past littered with cruelity, poverty, slavery, oppresion, injustice
A bit like the modern US of A then
The French only helped you lot to piss the English off. Not some idealistic crusade.
Oh, and the French went on an imperialistic rampage throughout Europe after toppling the monarchy, with associated cruelity, poverty, slavery, oppresion and injustice.
One reason, stated in the article, is that the UltraSPARC IIe uses only 13W of power for the CPU and intergrated memory controller and PCI controller. Apart from the main CPU, then, there'll be no chips requiring heat sinks, and very little heat to disperse. Less heat means generally more reliable if any other cooling fails (like A/C.)
What, like that north european rabble?
Of course, Americans (If you're one) are famous for getting bridges mixed up.
SCSI handles this with 'disconnects'. After the read command is sent, the controller disconnects from the bus. When the drive has read the data into it's buffers, it will send the data to the controller in a seperate transaction.
In the meantime, the bus is essentially idle, so other activity can occur.
Unlike ATA, SCSI is more like a packet switching bus, with multiple masters.
I have also wondered why more people aren't using the memory bus for peripherals....Seriously, the PCI buss can only offer so much (132 MB/S) which is certainly going to be a problem with anything faster than gigabit ethernet
Because the memory bus is a memory bus, and NOT a peripheral bus! Peripheral busses have things like interrupts, address space configuration, buffering, bridging, hot-plugging, and long-term stability that memory busses are simply not designed for.
How would you like it if you couldn't use the latest whizz bang 8.4GB/s memory technology because some peripheral you bought a year earlier needs to be on a 4.8GB/s memory interface?
Anyway, PCI v2.2 (?) offers 512MB/s in 64 bit 66MHz mode. And then there's PCI-X...
And show me a game that is PCI/AGP bandwidth limited once textures are uploaded to the GXF card anyway. Memory is cheap, use it...
Meanwhile, modern memory busses are upwards of 4.8Gb/s. Imagine multiple machines strung together with that kind of bandwidth between them!
Unfortunately, those pesky laws of physics (like the speed of light) come in and put paid to schemes like this. While it may be possible to get that bandwidth between machines, the latency becomes a problem. Certainly not feasable as a memory bus.
Were the majority of telephone systems still run by human operators as late as the late 60's to early 70's
No. I'm not sure about timescales, but in between human operators and electronic routing, there were mechanical based exchanges.
Basically, the old pulse dialing system would mechanically rotate a selector every pulse, then move to the next selector with each digit. The result was that routes between phones was selected machanically based on the pulsed phone number. My guess is that mechanical exchanges came in in the 1920s or 1930s.
Not sure how tone dialing came in. Probably the beginnings of elctronic exchanges. My guess here is 1950s or 1960s.
BTW, the actual exchanges are often MANAGED by UNIX systems, but don't actually run UNIX systems. The hardware itself is probably some custom embedded platform.
Finally, take the above with a grain of salt. I'm not a communications historian.
My Tekram DC-3903UW (Symbios 53c1010 based) uses is a 64 bit card (I think it can do 64x66MHz)
Thanks to the wonders of PCI, however, it works fine in my current 32x33 PCI slots.
Can't wait to get it onto one of these boards, as I have a couple of seagate cheatas striped on this baby, and I think PCI may be the performance bottleneck!
I've found that Solaris tends to support good quality hardware. No, you can't run a crap $5 no-name network card but you can run a nice Intel or 3com. Consequently if you build up a system to run Solaris, you are pretty much forced into building a good one. No bad thing IMHO.
Good quality? Branded, maybe, but price is no assurence of quality. Doesn't the Linux drivers at least have no end of hacks to get round bugs and/or design restrictions, certainly in the Intel based network cards. Try using an Intel network card with the default Windows NT drivers. Doesn't work, 'cos the hardware is broken.
My rtl8139 based £10 noname card has given me no problems. It certainly has some hacks in the drivers to work round a few problems, but show me hardware which doesn't.
I suppose Adaptec SCSI chips are so much better than Advansys or Symbios chipsets as well.
I find that 3Com, Adaptec and Intel are the IBMs of their respective markets. "You never get fired for buying..."
http://www.open2.net/dd100/elvis/elvis.html
The moral of the story, statistics need to be taken with a grain of salt.
Statements like:
Garvin said. "Java usage is even stronger outside North America, with almost 60 percent of developers expecting to spend some part of their programming time using Java."
Is that in their spare time, at work, what? How much real work will be done with Java as opposed to C/C++?
Intel had promised to supply IBM their processor, and signed AMD as their 2nd tier contractor to supply processors to IBM (boy, I'm sure some Intel execs are feeling really sorry for this now)..
Probably not. Without the PC deal, Intel may not have been the powerhouses they are today.
Except that several OSes were available for the PC, including CP/M and the USCD p-System, and later Xenix.
DOS wasn't huge, and could have been reverse engineered as easily as the BIOS. It was just a functional clone of CP/M, done in about 4 man months at Seattle Computer Products from whome MS bought the rights.
Of course not, it's not like the XP kernel was origionally developed on a MIPS based machine, now is it.
The NT kernel was designed to be portable from the outset, and has run on x86, MIPS, Alpha and PPC. Nothing ties the kernel to x86 other than market forces.
Now, as someone else commented about CDs and DVDs, YES, PLEASE, QUIET THESE HORRIBLE CONTRAPTIONS. My CD on my work computer has a cache that's just big enough to allow the drive to spin down for about 1/2 a second during a big transfer. Then it spins back up and transfers more. It's loud, it's annoying, and it turns this 40 some odd X CD Rom to about 10X.
Thats where caddy based CDROMs come in handy. My Plextor 32 speed drive can barely be heard. A great drive (though it isn't entirely agreeing with my new Muse album:( My guess is that is the CD though)
The drawback is that the larger number of instructions required to complete a given task is likely to take up a larger amount of space in RAM and on disk.
On the other side of the coin, most RISC chips also have more general purpose registers, and so can dispense with much of the register/memory shuffling that x86 typically has to do.
Just getting rid of some memory accesses, as well as removing redundant instructions, also speeds up execution as register/resgister operations are MUCH faster than even cached memeory accesses.