By: Jesper Frimann (jesperfrimann.delete@this.gmail.com), August 22, 2008 9:48 am
Room: Moderated Discussions
Tom W (twerges@hotmail.com) on 8/20/08 wrote:
---------------------------
>Jesper Frimann (jesperfrimann@gmail.com) on 8/20/08 wrote:
>---------------------------
>>Tom W (twerges@hotmail.com) on 8/19/08 wrote:
>>---------------------------
>>And there have been Big iron x86 boxes around for a long
>>time. But they generally are more expensive than their
>>risc/EPIC counterparts in TCO.
>
>Those big iron x86 boxes were not commodity boxes insofar as they required additional
>expensive hardware to allow pentium4 xeons to scale up to 32 processors. In the
>near future, however, nehalem will allow scaling up to 64 processors on commodity
>hardware. It seems possible that that would allow x86 boxes to be built which can
>scale up far enough, but which cost much less than their equivalent risc boxes,
>since the design cost per unit would be so much lower.
>
>>>The reliability features of high-end risc boxes are not features of the instruction set.
>>
>>They are, now get into the game.
>
>Are they? I remember learning assembly language for sparc and power when I was
>a student. I don't recall those architectures having instructions relevant to RAS.
>In fact most of the risc ISAs were developed for workstations and not for "big iron".
>
I saw a lecture by the guy that wrote Varnish, an open source web accelerator, on efficient
programming for modern computers, and one of his points was that the model you are taught on how
computers work at the University have very little to do with real life. Not sure that it's true
for all universities, I do remember having to write a multi tasking kernel in M68000 assembler on
second year, that was kind of close to the hardware :)=
But have a look at http://www.power.org/resources/reading/PowerISA_V2.05.pdf
For example Book III chapter 2.
Or just look at the instructions mfspr and mtspr.
>>And still if you compare the p570 to the x3950 with a x7460, then is a product with availability August 2007
>>compared to one with availability of December 2008 the power6 based p570 is still 25% faster per socket
>>and _FOUR_ times faster pr core.
>>
>>So the comparison is between a a future x86 product compared
>>to a current RISC product. And the furture x86 product still
>>gets creamed by a current RISC product.
>
>I don't doubt that power and itanium currently enjoy an advantage on TPC/C and
>other benchmarks. Probably, they will enjoy that advantage well into the future. I'm not contesting that.
>
>However, it appears to me that the time is coming when commodity x86 will be able
>to scale up far enough to meet almost everyone's needs. When that happens, I don't
>think so many people will be willing to pay the overhead imposed by architectures
>and instruction sets which have limited production runs and therefore have high
>design costs per unit. I realize that IBM gets around this issue to a large degree
>by using the same processor design in consoles.
>
>The places I've worked recently, there has always been tremendous resistance to
>that single big box which had a different architecture and OS from all the other
>servers in the place. It was not solely a matter of upfront costs. It was also a
>matter of lock-in, need for different admins to adminster the big box, incompatibility,
>uncertainty about the future of the proprietary platform, etc.
>
>Because of those things, I'd have to assume that many places would prefer not to
>use itanium or power if they thought x86 were seriously an option.
>
Yes I know that feeling, but when you drill down into those people what U'll find is that
much of that 'resistance to change', read one of my wife's books on psychology to learn that
phrase, is just that. Resistance to change. And when it comes down to it, it's not so much
x86 versus RISC/Itanium or Linux versus Unix but more the tools that people are actually using.
So normally it will be much easier for a guy to move from
HP x86,Linux,HP-insight Manager -> HP Itanium,Linux,HP insight Manager or perhaps even HP Itanium,HPUX, HP insight Manager
than it will be for that person to move to IBM x86,Linux,IBM Director.
So the lock in is in most cases on a higher level than the hardware. I mean most people use
windows servers cause the run windows only applications ontop of it.
I'd rather change from running Oracle on HPUX to Solaris than I'd change from running DB2 on HPUX to
running Oracle on HPUX, just to mention a fictive example.
>
>It seems possible to me, that once x86 overcomes it scalability problems, it may
>dominate the high end in the same way it dominated PCs, workstations, and low-end servers--and for the same reasons.
>
Well the highend server game is a totally different game. And if x86 wants to enter
this space it needs to gain many of the same features as the processors that play in
that space has. Furthermore the whole solution stack also have to be able to support
'highend server features' and not to forget the people running the servers.
You don't just boot a highend server if you have a problem.
You don't blindly accept that you have had 100% uptime over the last 2 years. It then
turns out that it's cause you don't collect downtime on your wintel servers.
At the moment I'm having a hard time trying to knock some sense into some Wintel VMware guys,
who simply cannot understand that a DB server running on a dedicated 8 way machine with 8 GB,
most likely can run virtualized on a UNIX box on perhaps as little as 2 Cores and 16 GB.
And that their 4 racks of Wintel/Lintel servers can be housed in very few Unix boxes, cause their
43 machines run at 4.57% average utilization, and if they move some of their batch jobs and backups
around, and if they choose to also distribute their workload evenly between the two sites, so as not to run
80% on one side and 20% on the other, then they can reduce the peak utilization from 35% to around 15-18%.
And if they wanna run Linux, No problem runs fine on both possible target platforms.
>>I must admit that I don't get this euphoria and well the
>>skadefryd/schadenfreude (danish/German word which means to
>>rejoice in others misfortune) that people express as the
>>x86 marked share rises.
>
>You might be misreading my intentions. There are differences between recognizing
>an inevitability and being euphoric about it.
>
That comment was not intended for you :)=
>>And many are talking about the prospect of a server marked
>>based solely on x86 as being a good thing.
>>IMHO that would be a terrible thing, a return to the days
>>where the IBM mainframe had monopoly, just with other
>>players sitting on the monopoly.
>
>I don't think we would return to the days of IBM mainframes, since there are so
>many manufacturers in the world which have licenses to make x86 chips. If we return
>to the days of monopoly, it will be because of the economics of chipmaking, which
>greatly favor larger players, and not because of intellectual property or lock-in.
Well the x86 game is Intel and then some smallish vendors that are struggling (sorry AMD).
And much of the innovation that you see on the box side of x86 servers are things that have
been copied from RISK/Itanium/Mainframe. The main innovation of the x86 server is the price, and
that have strictly speaking also been done before.
And with Intel trying hard to grab more and more of the infrastructure inside servers...
IMHO we are heading back to a world I personally don't care much for. And if that happens
I will either go back to software development or perhaps start that microbrewery that I've
been dreaming about.
// Jesper
---------------------------
>Jesper Frimann (jesperfrimann@gmail.com) on 8/20/08 wrote:
>---------------------------
>>Tom W (twerges@hotmail.com) on 8/19/08 wrote:
>>---------------------------
>>And there have been Big iron x86 boxes around for a long
>>time. But they generally are more expensive than their
>>risc/EPIC counterparts in TCO.
>
>Those big iron x86 boxes were not commodity boxes insofar as they required additional
>expensive hardware to allow pentium4 xeons to scale up to 32 processors. In the
>near future, however, nehalem will allow scaling up to 64 processors on commodity
>hardware. It seems possible that that would allow x86 boxes to be built which can
>scale up far enough, but which cost much less than their equivalent risc boxes,
>since the design cost per unit would be so much lower.
>
>>>The reliability features of high-end risc boxes are not features of the instruction set.
>>
>>They are, now get into the game.
>
>Are they? I remember learning assembly language for sparc and power when I was
>a student. I don't recall those architectures having instructions relevant to RAS.
>In fact most of the risc ISAs were developed for workstations and not for "big iron".
>
I saw a lecture by the guy that wrote Varnish, an open source web accelerator, on efficient
programming for modern computers, and one of his points was that the model you are taught on how
computers work at the University have very little to do with real life. Not sure that it's true
for all universities, I do remember having to write a multi tasking kernel in M68000 assembler on
second year, that was kind of close to the hardware :)=
But have a look at http://www.power.org/resources/reading/PowerISA_V2.05.pdf
For example Book III chapter 2.
Or just look at the instructions mfspr and mtspr.
>>And still if you compare the p570 to the x3950 with a x7460, then is a product with availability August 2007
>>compared to one with availability of December 2008 the power6 based p570 is still 25% faster per socket
>>and _FOUR_ times faster pr core.
>>
>>So the comparison is between a a future x86 product compared
>>to a current RISC product. And the furture x86 product still
>>gets creamed by a current RISC product.
>
>I don't doubt that power and itanium currently enjoy an advantage on TPC/C and
>other benchmarks. Probably, they will enjoy that advantage well into the future. I'm not contesting that.
>
>However, it appears to me that the time is coming when commodity x86 will be able
>to scale up far enough to meet almost everyone's needs. When that happens, I don't
>think so many people will be willing to pay the overhead imposed by architectures
>and instruction sets which have limited production runs and therefore have high
>design costs per unit. I realize that IBM gets around this issue to a large degree
>by using the same processor design in consoles.
>
>The places I've worked recently, there has always been tremendous resistance to
>that single big box which had a different architecture and OS from all the other
>servers in the place. It was not solely a matter of upfront costs. It was also a
>matter of lock-in, need for different admins to adminster the big box, incompatibility,
>uncertainty about the future of the proprietary platform, etc.
>
>Because of those things, I'd have to assume that many places would prefer not to
>use itanium or power if they thought x86 were seriously an option.
>
Yes I know that feeling, but when you drill down into those people what U'll find is that
much of that 'resistance to change', read one of my wife's books on psychology to learn that
phrase, is just that. Resistance to change. And when it comes down to it, it's not so much
x86 versus RISC/Itanium or Linux versus Unix but more the tools that people are actually using.
So normally it will be much easier for a guy to move from
HP x86,Linux,HP-insight Manager -> HP Itanium,Linux,HP insight Manager or perhaps even HP Itanium,HPUX, HP insight Manager
than it will be for that person to move to IBM x86,Linux,IBM Director.
So the lock in is in most cases on a higher level than the hardware. I mean most people use
windows servers cause the run windows only applications ontop of it.
I'd rather change from running Oracle on HPUX to Solaris than I'd change from running DB2 on HPUX to
running Oracle on HPUX, just to mention a fictive example.
>
>It seems possible to me, that once x86 overcomes it scalability problems, it may
>dominate the high end in the same way it dominated PCs, workstations, and low-end servers--and for the same reasons.
>
Well the highend server game is a totally different game. And if x86 wants to enter
this space it needs to gain many of the same features as the processors that play in
that space has. Furthermore the whole solution stack also have to be able to support
'highend server features' and not to forget the people running the servers.
You don't just boot a highend server if you have a problem.
You don't blindly accept that you have had 100% uptime over the last 2 years. It then
turns out that it's cause you don't collect downtime on your wintel servers.
At the moment I'm having a hard time trying to knock some sense into some Wintel VMware guys,
who simply cannot understand that a DB server running on a dedicated 8 way machine with 8 GB,
most likely can run virtualized on a UNIX box on perhaps as little as 2 Cores and 16 GB.
And that their 4 racks of Wintel/Lintel servers can be housed in very few Unix boxes, cause their
43 machines run at 4.57% average utilization, and if they move some of their batch jobs and backups
around, and if they choose to also distribute their workload evenly between the two sites, so as not to run
80% on one side and 20% on the other, then they can reduce the peak utilization from 35% to around 15-18%.
And if they wanna run Linux, No problem runs fine on both possible target platforms.
>>I must admit that I don't get this euphoria and well the
>>skadefryd/schadenfreude (danish/German word which means to
>>rejoice in others misfortune) that people express as the
>>x86 marked share rises.
>
>You might be misreading my intentions. There are differences between recognizing
>an inevitability and being euphoric about it.
>
That comment was not intended for you :)=
>>And many are talking about the prospect of a server marked
>>based solely on x86 as being a good thing.
>>IMHO that would be a terrible thing, a return to the days
>>where the IBM mainframe had monopoly, just with other
>>players sitting on the monopoly.
>
>I don't think we would return to the days of IBM mainframes, since there are so
>many manufacturers in the world which have licenses to make x86 chips. If we return
>to the days of monopoly, it will be because of the economics of chipmaking, which
>greatly favor larger players, and not because of intellectual property or lock-in.
Well the x86 game is Intel and then some smallish vendors that are struggling (sorry AMD).
And much of the innovation that you see on the box side of x86 servers are things that have
been copied from RISK/Itanium/Mainframe. The main innovation of the x86 server is the price, and
that have strictly speaking also been done before.
And with Intel trying hard to grab more and more of the infrastructure inside servers...
IMHO we are heading back to a world I personally don't care much for. And if that happens
I will either go back to software development or perhaps start that microbrewery that I've
been dreaming about.
// Jesper
Topic | Posted By | Date |
---|---|---|
First Dunnington benchmark results | Michael S | 2008/08/19 10:54 AM |
First Dunnington benchmark results | rwessel | 2008/08/19 01:42 PM |
First Dunnington benchmark results | Aaron Apink | 2008/08/19 05:49 PM |
First Dunnington benchmark results | Joe Chang | 2008/08/19 06:28 PM |
First Dunnington benchmark results | rwessel | 2008/08/21 09:49 AM |
First Dunnington benchmark results | Joe Chang | 2008/08/21 03:10 PM |
First Dunnington benchmark results | rwessel | 2008/08/21 06:42 PM |
First Dunnington benchmark results | Joe Chang | 2008/08/21 07:12 PM |
First Dunnington benchmark results | rwessel | 2008/08/21 09:45 AM |
First Dunnington benchmark results | Aaron Spink | 2008/08/21 01:12 PM |
First Dunnington benchmark results | Joe Chang | 2008/08/21 03:15 PM |
First Dunnington benchmark results | Richard Cownie | 2008/08/20 02:59 AM |
First Dunnington benchmark results | Anders Jensen | 2008/08/20 03:26 AM |
+SSD | Anders Jensen | 2008/08/20 03:30 AM |
First Dunnington benchmark results | Richard Cownie | 2008/08/20 11:04 AM |
First Dunnington benchmark results | slacker | 2008/08/20 12:35 PM |
First Dunnington benchmark results | Doug Siebert | 2008/08/20 07:54 PM |
First Dunnington benchmark results | Richard Cownie | 2008/08/20 08:58 PM |
SLC vs. MLC | David Kanter | 2008/08/21 01:16 AM |
SLC vs. MLC | Matt Sayler | 2008/08/21 06:25 AM |
SLC vs. MLC | Richard Cownie | 2008/08/21 06:32 AM |
SLC vs. MLC | Linus Torvalds | 2008/08/21 08:39 AM |
SLC vs. MLC | Michael S | 2008/08/21 09:07 AM |
SLC vs. MLC | Linus Torvalds | 2008/08/21 09:52 AM |
SLC vs. MLC | Michael S | 2008/08/21 10:35 AM |
OLTP appliance = mainframe? (NT) | Potatoswatter | 2008/08/21 11:44 AM |
OLTP appliance = HP NonStop? | Michael S | 2008/08/21 12:03 PM |
OLTP appliance | Joe Chang | 2008/08/21 03:33 PM |
OLTP appliance | Potatoswatter | 2008/08/21 03:59 PM |
SLC vs. MLC | Aaron Spink | 2008/08/21 01:29 PM |
SLC vs. MLC | Dan Downs | 2008/08/21 11:33 AM |
SLC vs. MLC | rwessel | 2008/08/21 12:45 PM |
SLC vs. MLC | Dan Downs | 2008/08/22 08:21 AM |
SLC vs. MLC | Aaron Spink | 2008/08/21 01:34 PM |
SLC vs. MLC vs DRAM | pgerassi | 2008/08/21 12:24 PM |
SLC vs. MLC vs DRAM | David Kanter | 2008/08/22 01:31 AM |
SLC vs. MLC | Groo | 2008/08/23 12:52 PM |
SLC vs. MLC | Doug Siebert | 2008/08/21 06:14 PM |
SLC vs. MLC | Linus Torvalds | 2008/08/22 08:05 AM |
SLC vs. MLC | Doug Siebert | 2008/08/22 02:27 PM |
SLC vs. MLC | EduardoS | 2008/08/22 06:26 PM |
SSD Controller differentiation | David Kanter | 2008/08/22 09:35 PM |
SSD Controller differentiation | Doug Siebert | 2008/08/22 10:34 PM |
SSD Controller differentiation (supercaps, cost...) | anon | 2008/08/23 10:18 AM |
SSD Controller differentiation (supercaps, cost...) | Doug Siebert | 2008/08/23 10:40 AM |
SLC vs. MLC | Linus Torvalds | 2008/08/23 10:50 AM |
SLC vs. MLC | Linus Torvalds | 2008/09/08 12:03 PM |
SLC vs. MLC | Max | 2008/09/08 01:51 PM |
SLC vs. MLC | Howard Chu | 2008/09/08 09:04 PM |
SLC vs. MLC | Max | 2008/09/08 10:29 PM |
SLC vs. MLC | Howard Chu | 2008/09/09 12:12 AM |
RAM vs SSD? | Jouni Osmala | 2008/09/09 01:06 AM |
RAM vs SSD? | Max | 2008/09/12 12:51 PM |
RAM vs SSD? | EduardoS | 2008/09/12 04:27 PM |
Disk cache snapshotting | Max | 2008/09/13 08:34 AM |
Disk cache snapshotting | Howard Chu | 2008/09/14 09:58 PM |
Disk cache snapshotting | Max | 2008/09/15 12:50 PM |
SLC vs. MLC | Linus Torvalds | 2008/09/09 07:43 AM |
SLC vs. MLC | Howard Chu | 2008/09/09 09:42 AM |
SLC vs. MLC | Linus Torvalds | 2008/09/09 10:39 AM |
SLC vs. MLC | Michael S | 2008/09/10 12:29 AM |
SLC vs. MLC | anon | 2008/09/10 02:51 AM |
SLC vs. MLC | Michael S | 2008/09/10 03:09 AM |
SLC vs. MLC | Max | 2008/09/10 04:48 AM |
SLC vs. MLC | Michael S | 2008/09/10 05:52 AM |
SLC vs. MLC | Max | 2008/09/10 06:28 AM |
SLC vs. MLC | Matt Sayler | 2008/09/10 06:21 AM |
SLC vs. MLC | Michael S | 2008/09/10 09:17 AM |
SLC vs. MLC | anon | 2008/09/10 06:29 AM |
SLC vs. MLC | Michael S | 2008/09/10 09:23 AM |
SLC vs. MLC | Matt Sayler | 2008/09/10 10:45 AM |
SLC vs. MLC | Linus Torvalds | 2008/09/10 07:25 AM |
SLC vs. MLC | Michael S | 2008/09/10 09:54 AM |
SLC vs. MLC | Linus Torvalds | 2008/09/10 10:31 AM |
Physical vs effective write latency | Max | 2008/09/11 07:35 AM |
Physical vs effective write latency | Linus Torvalds | 2008/09/11 09:06 AM |
Physical vs effective write latency | Linus Torvalds | 2008/09/11 09:48 AM |
Physical vs effective write latency | Linus Torvalds | 2008/09/11 11:39 AM |
Physical vs effective write latency | Mark Roulo | 2008/09/11 12:18 PM |
Physical vs effective write latency | Doug Siebert | 2008/09/11 05:59 PM |
Physical vs effective write latency | Linus Torvalds | 2008/09/11 07:16 PM |
Physical vs effective write latency | Doug Siebert | 2008/09/11 10:28 PM |
Physical vs effective write latency | MS | 2009/02/03 03:06 PM |
SLC vs. MLC - the trick to latency | Anonymous | 2008/09/11 12:39 PM |
SLC vs. MLC - the trick to latency | anon | 2008/09/11 01:17 PM |
SLC vs. MLC - the trick to latency | Anonymous | 2008/09/11 05:25 PM |
SLC vs. MLC - the trick to latency | Doug Siebert | 2008/09/11 05:47 PM |
SLC vs. MLC - the trick to latency | rwessel | 2008/09/11 06:01 PM |
SLC vs. MLC - the trick to latency | anon | 2008/09/12 12:00 AM |
SLC vs. MLC - the trick to latency | Anonymous | 2008/09/12 08:52 PM |
SLC vs. MLC - the trick to latency | anon | 2008/09/13 10:06 AM |
SLC vs. MLC - the trick to latency | Ungo | 2008/09/15 12:18 PM |
To SSD or not? One lady's perspective | David Kanter | 2008/09/22 01:12 AM |
To SSD or not? One lady's perspective | Howard Chu | 2008/09/22 04:02 AM |
To SSD or not? Real data.. | Linus Torvalds | 2008/09/22 07:33 AM |
To SSD or not? Real data.. | Ungo | 2008/09/22 12:27 PM |
4K sectors | Wes Felter | 2008/09/22 06:03 PM |
4K sectors | Daniel | 2008/09/22 10:31 PM |
Reasons for >512 byte sectors | Doug Siebert | 2008/09/22 09:38 PM |
Reasons for >512 byte sectors | rwessel | 2008/09/22 10:09 PM |
Reasons for >512 byte sectors | Howard Chu | 2008/09/23 02:50 AM |
Reasons for >512 byte sectors | Daniel | 2008/09/22 10:40 PM |
Reasons for >512 byte sectors | rwessel | 2008/09/23 09:11 AM |
Reasons for >512 byte sectors | Daniel | 2008/09/23 12:10 PM |
HDD long sector size availability | Etienne Lehnart | 2008/09/23 05:32 AM |
HDD long sector size availability | rwessel | 2008/09/23 09:19 AM |
HDD long sector size availability | Etienne Lehnart | 2008/09/23 02:17 PM |
To SSD or not? Real data.. | Jouni Osmala | 2008/09/22 11:16 PM |
To SSD or not? One lady's perspective | Wes Felter | 2008/09/22 11:25 AM |
How should SSDs be engineered into systems? | Rob Thorpe | 2008/09/22 02:01 PM |
How should SSDs be engineered into systems? | Matt Craighead | 2008/09/23 06:59 PM |
How should SSDs be engineered into systems? | Matt Sayler | 2008/09/24 04:17 AM |
ATA/SCSIS, Write Flushes and Asych Filesystems | TruePath | 2009/01/25 04:44 AM |
SLC vs. MLC - the trick to latency | Michael S | 2008/09/12 04:58 AM |
overlapped erase and read | Michael S | 2008/09/12 04:59 AM |
overlapped erase and read | David W. Hess | 2008/09/12 09:56 AM |
overlapped erase and read | Anonymous | 2008/09/12 08:45 PM |
overlapped erase and read | Jouni Osmala | 2008/09/12 11:56 PM |
overlapped erase and read | Michael S | 2008/09/13 11:29 AM |
overlapped erase and read | Michael S | 2008/09/13 12:09 PM |
overlapped erase and read | Linus Torvalds | 2008/09/13 02:05 PM |
SLC vs. MLC - the trick to latency | Doug Siebert | 2008/09/11 05:31 PM |
SLC vs. MLC | EduardoS | 2008/09/08 02:07 PM |
SLC vs. MLC | Linus Torvalds | 2008/09/08 02:30 PM |
SLC vs. MLC | EduardoS | 2008/09/08 04:01 PM |
SSD and RAID | Joe Chang | 2008/09/08 07:42 PM |
SSD and RAID | Doug Siebert | 2008/09/08 09:46 PM |
SSD and RAID | Aaron Spink | 2008/09/09 04:27 PM |
SSD and RAID | Groo | 2008/09/10 01:02 PM |
SLC vs. MLC | Joern Engel | 2009/01/06 10:22 AM |
SLC vs. MLC | Linus Torvalds | 2009/01/06 02:04 PM |
SLC vs. MLC | Joern Engel | 2009/01/06 03:24 PM |
SLC vs. MLC | rwessel | 2009/01/06 04:47 PM |
SLC vs. MLC | anonymous | 2009/01/06 05:17 PM |
SLC vs. MLC | rwessel | 2009/01/06 05:58 PM |
SLC vs. MLC | Joern Engel | 2009/01/07 12:35 AM |
SLC vs. MLC | Linus Torvalds | 2009/01/06 05:45 PM |
SLC vs. MLC | rwessel | 2009/01/06 06:09 PM |
SLC vs. MLC | Linus Torvalds | 2009/01/06 07:47 PM |
SLC vs. MLC | Joern Engel | 2009/01/07 12:26 AM |
SLC vs. MLC | anon | 2009/01/06 08:23 PM |
SLC vs. MLC | Joern Engel | 2009/01/07 12:52 AM |
SLC vs. MLC | anon | 2009/01/07 02:34 AM |
SLC vs. MLC | IntelUser2000 | 2009/01/07 07:43 AM |
SLC vs. MLC | Linus Torvalds | 2009/01/07 10:28 AM |
drop data filesystem semantic | Doug Siebert | 2009/01/09 12:21 PM |
FTL and FS | iz | 2009/01/09 07:49 PM |
FTL and FS | Linus Torvalds | 2009/01/09 09:53 PM |
FTL and FS | iz | 2009/01/10 02:09 AM |
FTL and FS | Michael S | 2009/01/10 03:19 PM |
compiling large programs | iz | 2009/01/10 05:51 PM |
compiling large programs | Linus Torvalds | 2009/01/10 07:58 PM |
compiling large programs | peter | 2009/01/11 05:30 AM |
compiling large programs | Andi Kleen | 2009/01/11 01:03 PM |
The File Abstraction | TruePath | 2009/01/25 06:45 AM |
The File Abstraction | Howard Chu | 2009/01/25 01:49 PM |
The File Abstraction | Linus Torvalds | 2009/01/26 09:23 AM |
The File Abstraction | Michael S | 2009/01/26 01:39 PM |
The File Abstraction | Linus Torvalds | 2009/01/26 02:31 PM |
The File Abstraction | Dean Kent | 2009/01/26 03:06 PM |
The File Abstraction | Linus Torvalds | 2009/01/26 04:29 PM |
The File Abstraction | Mark Christiansen | 2009/01/27 09:24 AM |
The File Abstraction | Mark Christiansen | 2009/01/27 10:14 AM |
The File Abstraction | Linus Torvalds | 2009/01/27 10:15 AM |
The File Abstraction | slacker | 2009/01/27 11:20 AM |
The File Abstraction | Linus Torvalds | 2009/01/27 01:16 PM |
Attributes All The Way Down | Mark Christiansen | 2009/01/27 02:17 PM |
The File Abstraction | slacker | 2009/01/27 05:25 PM |
The File Abstraction | Linus Torvalds | 2009/01/28 08:17 AM |
The File Abstraction: API thoughts | Carlie Coats | 2009/01/28 09:35 AM |
The File Abstraction | slacker | 2009/01/28 10:09 AM |
The File Abstraction | Linus Torvalds | 2009/01/28 01:44 PM |
Programs already 'hide' their metadata in the bytestream, unbeknownst to users | anon | 2009/01/28 09:28 PM |
The File Abstraction | slacker | 2009/01/29 10:39 AM |
The File Abstraction | Linus Torvalds | 2009/01/29 11:08 AM |
The File Abstraction | Dean Kent | 2009/01/29 11:49 AM |
The File Abstraction | Howard Chu | 2009/01/29 02:58 PM |
The File Abstraction | rwessel | 2009/01/29 04:23 PM |
Extended Attributes in Action | slacker | 2009/01/29 03:05 PM |
Extended Attributes in Action | stubar | 2009/01/29 04:49 PM |
Extended Attributes in Action | Linus Torvalds | 2009/01/29 05:15 PM |
Like Duh | anon | 2009/01/29 07:42 PM |
Like Duh | anon | 2009/01/29 09:15 PM |
Like Duh | anon | 2009/02/01 07:18 PM |
Double Duh. | Anonymous | 2009/02/01 10:58 PM |
Double Duh. | anon | 2009/02/02 02:08 AM |
Double Duh. | Anonymous | 2009/02/02 05:11 PM |
Double Duh. | anon | 2009/02/02 07:33 PM |
Like Duh | David Kanter | 2009/02/01 11:05 PM |
Like Duh | peter | 2009/02/01 11:55 PM |
Like Duh | anon | 2009/02/02 01:55 AM |
Xattrs, Solar power, regulation and politics | Rob Thorpe | 2009/02/02 04:36 AM |
Terminology seems too fuzzy to me | hobold | 2009/02/02 06:14 AM |
Terminology seems too fuzzy to me | rwessel | 2009/02/02 12:33 PM |
good summary | Michael S | 2009/02/03 02:41 AM |
good summary | Mark Christiansen | 2009/02/03 09:57 AM |
good summary | Howard Chu | 2009/02/03 10:21 AM |
good summary | Mark Christiansen | 2009/02/03 11:18 AM |
good summary | Howard Chu | 2009/02/03 12:00 PM |
good summary | Mark Christiansen | 2009/02/03 12:36 PM |
good summary | RagingDragon | 2009/02/03 10:39 PM |
good summary | rwessel | 2009/02/03 11:03 PM |
good summary | RagingDragon | 2009/02/03 11:46 PM |
Terminology seems too fuzzy to me | slacker | 2009/02/04 05:06 PM |
Terminology seems too fuzzy to me | Michael S | 2009/02/05 01:05 AM |
Terminology seems too fuzzy to me | Ungo | 2009/02/05 01:15 PM |
Terminology seems too fuzzy to me | slacker | 2009/02/05 02:19 PM |
Terminology seems too fuzzy to me | Howard Chu | 2009/02/05 04:44 PM |
Like Duh | iz | 2009/01/30 02:03 AM |
EAs (security labels) hosed me badly | anon | 2009/01/30 09:48 PM |
Extended Attributes in Action | RagingDragon | 2009/01/29 09:31 PM |
Extended Attributes in Action | anonymous | 2009/01/29 08:13 PM |
Extended Attributes in Action | Howard Chu | 2009/01/29 09:38 PM |
Extended Attributes in Action | slacker | 2009/01/30 11:24 AM |
Extended Attributes in Action | anon | 2009/01/30 05:50 PM |
Extended Attributes in Action | Etienne Lehnart | 2009/01/30 12:22 AM |
Extended Attributes in Action | Rob Thorpe | 2009/01/30 12:39 PM |
Extended Attributes in Action | slacker | 2009/01/30 01:16 PM |
Extended Attributes in Action | anon | 2009/01/30 06:03 PM |
Extended Attributes in Action | Howard Chu | 2009/01/30 11:22 PM |
Extended Attributes in Action | rwessel | 2009/01/31 12:08 AM |
Extended Attributes in Action | anonymous | 2009/01/31 12:22 AM |
Extended Attributes in Action | rwessel | 2009/01/31 12:56 AM |
Scaling | Dean Kent | 2009/01/31 09:04 AM |
Scaling | Rob Thorpe | 2009/02/02 02:39 AM |
Scaling | rwessel | 2009/02/02 11:41 AM |
Scaling | Howard Chu | 2009/02/02 12:30 PM |
Scaling | Dean Kent | 2009/02/02 02:27 PM |
Scaling | Rob Thorpe | 2009/02/03 05:08 AM |
Scaling | Dean Kent | 2009/02/03 07:38 AM |
Scaling | rwessel | 2009/02/03 02:34 PM |
Scaling | RagingDragon | 2009/02/03 10:46 PM |
in defense of software that does not scale | Matt Sayler | 2009/02/03 11:27 AM |
in defense of software that does not scale | Howard Chu | 2009/02/03 12:03 PM |
in defense of software that does not scale | Matt Sayler | 2009/02/03 12:17 PM |
in defense of software that does not scale | RagingDragon | 2009/02/03 11:00 PM |
in defense of software that does not scale | Michael S | 2009/02/04 06:46 AM |
in defense of software that does not scale | RagingDragon | 2009/02/04 09:33 PM |
in defense of software that does not scale | Dean Kent | 2009/02/03 12:17 PM |
in defense of software that does not scale | Matt Sayler | 2009/02/03 12:24 PM |
in defense of software that does not scale | Vincent Diepeveen | 2009/02/04 10:43 AM |
in defense of software that does not scale | rwessel | 2009/02/03 02:44 PM |
in defense of software that does not scale | anon | 2009/02/04 02:35 AM |
in defense of software that does not scale | Carlie Coats | 2009/02/04 05:24 AM |
Scaling with time vs. scaling from the beginning. | mpx | 2009/02/05 01:57 AM |
Extended Attributes in Action | Michael S | 2009/01/31 10:33 AM |
Extended Attributes in Action | anon | 2009/01/31 10:37 PM |
Extended Attributes in Action | JasonB | 2009/01/31 08:11 AM |
Extended Attributes in Action | Howard Chu | 2009/01/31 11:43 AM |
Extended Attributes in Action | JasonB | 2009/01/31 04:37 PM |
Extended Attributes in Action | Howard Chu | 2009/02/02 02:42 PM |
Extended Attributes in Action | Howard Chu | 2009/02/02 02:44 PM |
The File Abstraction | Rob Thorpe | 2009/01/27 11:20 AM |
The File Abstraction | Howard Chu | 2009/01/27 12:28 AM |
The File Abstraction | Michael S | 2009/01/27 03:00 AM |
The File Abstraction | Dean Kent | 2009/01/27 08:30 AM |
The File Abstraction | Andi Kleen | 2009/01/27 02:05 AM |
SLC vs. MLC | Michel | 2009/01/12 06:54 PM |
SLC vs. MLC | Linus Torvalds | 2009/01/12 07:38 PM |
SLC vs. MLC | rwessel | 2009/01/13 12:52 AM |
SLC vs. MLC | Ungo | 2009/01/13 03:04 PM |
SLC vs. MLC | Wes Felter | 2009/01/13 05:42 PM |
SLC vs. MLC | TruePath | 2009/01/25 05:05 AM |
SLC vs. MLC | Ungo | 2008/08/21 12:54 PM |
SLC vs. MLC | Aaron Spink | 2008/08/21 01:20 PM |
MLC vs. SLC | Michael S | 2008/08/21 08:57 AM |
First Dunnington benchmark results | rwessel | 2008/08/21 10:40 AM |
First Dunnington benchmark results | Aaron Spink | 2008/08/21 03:18 AM |
First Dunnington benchmark results | Etienne Lehnart | 2008/08/20 04:38 AM |
Will x86 dominate big iron? | Tom W | 2008/08/19 10:10 PM |
Will x86 dominate big iron? | Jesper Frimann | 2008/08/20 12:28 AM |
Will x86 dominate big iron? | Tom W | 2008/08/20 03:42 PM |
Will x86 dominate big iron? | David Kanter | 2008/08/21 01:13 AM |
Will x86 dominate big iron? | Joe Chang | 2008/08/21 06:54 AM |
Will x86 dominate big iron? | asdf | 2008/08/22 01:18 PM |
Will x86 dominate big iron? | Dean Kent | 2008/08/22 07:54 PM |
Will x86 dominate big iron? | Jesper Frimann | 2008/08/22 09:48 AM |
Will x86 dominate big iron? | Tom W | 2008/08/24 01:06 AM |
Will x86 dominate big iron? | Michael S | 2008/08/24 04:19 AM |
Will x86 dominate big iron? | Dean Kent | 2008/08/24 09:30 AM |
Will x86 dominate big iron? | Paul | 2008/08/24 11:16 AM |
Will x86 dominate big iron? | Dean Kent | 2008/08/24 12:37 PM |
Will x86 dominate big iron? | Michael S | 2008/08/25 12:53 AM |
Will x86 dominate big iron? | someone | 2008/08/22 10:19 AM |
Will x86 dominate big iron? | aaron spink | 2008/08/23 02:56 AM |
Will x86 dominate big iron? | Michael S | 2008/08/23 09:58 AM |
Will x86 dominate big iron? | someone | 2008/08/23 01:51 PM |
Will x86 dominate big iron? | someone | 2008/08/23 01:55 PM |
Will x86 dominate big iron? | Aaron Spink | 2008/08/23 04:52 PM |
Will x86 dominate big iron? | anonymous | 2008/08/23 05:28 PM |
Will x86 dominate big iron? | Dean Kent | 2008/08/23 06:12 PM |
Off road and topic | EduardoS | 2008/08/23 06:28 PM |
Will x86 dominate big iron? | someone | 2008/08/23 06:26 PM |
Will x86 dominate big iron? | Dean Kent | 2008/08/23 09:40 PM |
Will x86 dominate big iron? | anonymous | 2008/08/24 01:46 AM |
Off road and topic | David W. Hess | 2008/08/24 03:24 AM |
Off road and topic | Aaron Spink | 2008/08/24 04:14 AM |
Beckton vs. Dunnington | Mr. Camel | 2008/08/22 06:30 AM |
Beckton vs. Dunnington | jokerman | 2008/08/22 12:12 PM |
Beckton vs. Dunnington | Mr. Camel | 2009/05/29 10:16 AM |