Interesting. In that case, should I be blaming Linus for not supporting an industry "standard" in the first place? Or is it as much a moving target as other Microsoft standards?
Although, I do blame Linus for his poor decision to make kernel drivers version specific...
I did say "eventually". The trick is, Microsoft has been trying to lay low ever since the Anti-Trust proceedings took place. They weren't able to convince their original judge, but by playing nice, they were able to get the appeals court to let them off the hook. And yet, that same appeals court could crucify them if Microsoft dared to make blatant violations of their anti-trust agreements. That's why they haven't outright crushed or bought out Linux distributors and their specs are no longer the moving target they once were. Both of those actions would be looked upon poorly by a court of law.
> NDIS is a cross-platform network driver model, or at > least it was when I worked with it ~10 years ago.
Are we talking about the same NDIS? The info page describes NDIS as a DLL loader and Windows driver interface. There's nothing there to indicate that it's based on a standard that was around since before Windows 95.
> If Microsoft doesn't support the driver model, none of the > current Windows IHVs will either.
That depends on how much cross platform support is worth to them. If the ability to release the same driver for Window, Linux, and FreeBSD exists, and you need support for multiple platforms to compete, why not use it? Not to mention that it would simplify porting between Windows versions. Right now, IHVs are screwed over every time Microsoft releases a new version of Windows. Now, instead of going back and rewriting their drivers to work with yet another DDI change, they simply have to recompile against a new adapter.
Remember, the people who write these drivers are programmers just like you and I. If you could give them a good technical solution, they'll take it. All their boss will notice is that his programmer(s) seem to be porting a hell of a lot faster than before.
That's not a particularly helpful response. For example:
Do you think hardware vendors want to have lawyers fucking them with a service pack?
Only if Microsoft wants to keep going to court for Anti-Trust violations. If they kept pulling crap like that, eventually they'll screw up so badly that every judge in the US is going to throw the book at them.
> Because there's absolutely no business reason why > Microsoft would care to support such a standard?
The adapter I'm describing requires nothing from the OS vendor. Yes, someone will still have to code the OS specific adapter code, but that's not necessarily the vendor. Once completed, the adapter would plug in like a normal driver and all Cross Platform drivers would plug into the adapter.
For quite a while now, I've considered what sorts of problems would be inherent in cross platform drivers. Usually, the problem seems to come back to a difference in the way kernels manage their drivers and differences in the way that I/O is done between OSes. Perhaps a "Driver Adapter" could be built that would allow drivers written for it to run on any OS? The basic concept is that the adapter itself would be a driver for the OS, then the "Cross Platform Drivers" would deal directly with the adapter.
Anyone have any thoughts on why this would or wouldn't work?
Okay 32,768 colors. So sue me.:-) Since most games were very cartoony in nature, it wasn't usually obvious that the screen was palette swapping. And IIRC, the more advanced scaling and rotation stuff was called "Mode 7" or something like that. The first game to show it off was the second game released for the SNES: the psuedo 3D "Pilot Wings".
Ah, memories. Of course, with hit titles like "Sim City", "TMNT 4", "Street Fighter 2", "Contra III", "F-Zero" and "Zelda 3: A Link to the Past", the SNES was a shoe in.
Actually, the processors in home consoles have traditionally sucked. What makes them useful (and impressive) is the video hardware that does all the work. Let's take the Super Nintendo as an example. This machine could barely manage a few megahertz, yet it was scaling/rotating/blitting out hi-res graphics with millions of colors. How did it do it? Well, there was Sprite based hardware that could take a section of memory and generate a video overlay signal directly off that memory. The processor simply had to say "move it here" or "scale it by this much" and the hardware did it. There was no "blitting" as we think of it on PCs.
Of course, this meant the hardware was limited to the maximum number of sprites that could be handled in hardware at a given time. In fact, You may have noticed an artifact of this approach when too many sprites got on the screen and all the characters started flickering. Still, the results were impressive and PCs couldn't hold a candle.
Now, when 3D graphics came along, PCs (for the first time ever) ended up using the same video hardware as consoles. Consoles still had some advantages in the area of special optimizations and platform consistency, but the performance gap was narrowing.
What do we have today? PCs dressed up like consoles. (i.e. XBox)
> I thought that the Athlon 64 and Opteron were > currently limited to 48 bits of address space, for > packaging reasons?
The design can address 64 bits. It's physical ability to support memory is limited by the motherboard. For example, the Intel Pentium architecture can address 4 gigs, but consumer motherboards tend to have maximums of 512MB to 2Gigs.
>> The current definition of a 64 bit processor is one that >> can use 64 bit memory addressing. > >So.. a processor that can understand 64-bit numbers.
Do you have any idea what "64 bit memory addressing" means? It doesn't mean math. It means "more pigeon holes to put stuff in". There are two things stopping modern processors from going to 64 bit addressing:
1. Comatibility 2. More complex and expensive memory controllers, motherboards, bus designs, etc.
The silicon on the chip is the least of our concerns.
> (This was before the days of on-board video memory.)
Incorrect. EGA and VGA cards had onboard memory that was *mapped* to the A000 and B000 ranges. That memory was reserved because IBM didn't want to deal with direct I/O port communications in software. The only part that sucked was that they used so much memory. I mean really, did they need to whole B000 range for text mode graphics? And why couldn't we use the same memory for graphics and text?
Of course, some memory extenders would try to detect what video mode you were in and make use of the extra memory.:-)
a 32 bit machine working on 64 bit numbers involves multiple iterations of the same units... obviously a computer can work on arbitrary sized bit fields.. it can do 900 bit math, too.....
but at it's heart, it's doing 32 bit stuff.
Not true. Most modern processors have silicon dedicated to processing 64 bit numbers. In fact, most processors can do 128 bit numbers thanks to SMID instructions (e.g. SSE, 3DNow, Altivec, etc.)
The current definition of a 64 bit processor is one that can use 64 bit memory addressing.
> Hum, seems like several companies have handled the > memory issue. How the heck are they getting away with > 64GIGS of memory on some of these 32bit servers?
It's called segmented memory. Remember the old DOS days when programs couldn't address more than 64K of memory without adding special "Large Model" addressing? Well it's baaaackkk! No program can access more than 4 gigs of RAM without being compiled specifically to bank switch. Thus, you can have multiple programs that can all run with up to 4 gigs of RAM, but none of those programs will be able to process more data than that. 64 bit processors make this easy by allowing flat addressing of >4Gigs. Just like how 32bit processors allowed addressing of >1024K (minus the ~300K that IBM "reserved").
> And did you know AMD is sending free amd64 arch > manuals (4 nice books) freely to anyone in US and > Canada? Did you?
Did you know that Intel had free manuals years before the AMD64 was introduced? Did you!? And did you know that they are NICE manuals that are carefully packed, unlike my AMD64 manuals which are flimsy and arrived with water damage? Did you!?
Yes, that's the REAL issue for switching. The REAL issue for time is simply to get programs to switch over to using 64 bit time APIs. Nothing to do with 64/32 bit processors. Sorry if I was confusing on that point.
I'm not in a hurry to ditch any of my 32-bit machines, so long as I get them replaced by 2038.
I hope the editors realize that 32bit processors CAN process 64 bit numbers. In Java, for example, the date is handled by a 64bit number that tells the number of milliseconds since Jan 1, 1970. Amazingly enough, that clock won't run out for another few billion years.
Oh, and most Unixes have fixed the time problem. The real issue is getting the programs to switch over to the new APIs.
Re:Full text searching improved and other goodness
on
PostgreSQL 7.4 Released
·
· Score: 2, Informative
> Does PostgreSQL have a good GUI component for direct database manipulation?
Traditionally, this has been the job of third party developers. SQL Server is the one exception as it tries to make you dependent on the GUI tools. Still, if you want a GUI tool, both pgAdmin and my own DataDino are good alternatives.
> The alternatives being ssh and using the DB's shell or some client GUI tool
You forgot about the advantage of not leaving the database port open to the internet. Many databases are rather lax when it comes to security, simply assuming that you'll keep them behind a firewall. Despite that, I know of quite a few people who use DataDino over dial-up. Having a full blown GUI tool gives them a lot of flexibility, but you have to wonder how safe it is.
Of course, that's assuming that anyone wants your data to begin with...
Sorry for the self-promotion, but you might give DataDino a try. It should do everything you need WITHOUT requiring you to compile and install every ODBC driver yourself (a big problem on OS X).
Well, I suppose it doesn't have the Excel thing, but you could put in an enhancement request...
No argument here. My only point was that we can't just send it "floating off" into deep space and hope it takes some good pictures. The Hubble isn't properly equipped nor do we have off the shelf equipment that could perform the task for the Hubble. Either they've got to service it or deorbit it. Both options would tend to equate to a stop over of the shuttle or some other automated satellite. The one other option is an explosive missile, but that tends to add more space junk in the skies.
Slashdot Mirror
Interesting. In that case, should I be blaming Linus for not supporting an industry "standard" in the first place? Or is it as much a moving target as other Microsoft standards?
Although, I do blame Linus for his poor decision to make kernel drivers version specific...
I did say "eventually". The trick is, Microsoft has been trying to lay low ever since the Anti-Trust proceedings took place. They weren't able to convince their original judge, but by playing nice, they were able to get the appeals court to let them off the hook. And yet, that same appeals court could crucify them if Microsoft dared to make blatant violations of their anti-trust agreements. That's why they haven't outright crushed or bought out Linux distributors and their specs are no longer the moving target they once were. Both of those actions would be looked upon poorly by a court of law.
> NDIS is a cross-platform network driver model, or at
> least it was when I worked with it ~10 years ago.
Are we talking about the same NDIS? The info page describes NDIS as a DLL loader and Windows driver interface. There's nothing there to indicate that it's based on a standard that was around since before Windows 95.
> If Microsoft doesn't support the driver model, none of the
> current Windows IHVs will either.
That depends on how much cross platform support is worth to them. If the ability to release the same driver for Window, Linux, and FreeBSD exists, and you need support for multiple platforms to compete, why not use it? Not to mention that it would simplify porting between Windows versions. Right now, IHVs are screwed over every time Microsoft releases a new version of Windows. Now, instead of going back and rewriting their drivers to work with yet another DDI change, they simply have to recompile against a new adapter.
Remember, the people who write these drivers are programmers just like you and I. If you could give them a good technical solution, they'll take it. All their boss will notice is that his programmer(s) seem to be porting a hell of a lot faster than before.
That's not a particularly helpful response. For example:
Do you think hardware vendors want to have lawyers fucking them with a service pack?
Only if Microsoft wants to keep going to court for Anti-Trust violations. If they kept pulling crap like that, eventually they'll screw up so badly that every judge in the US is going to throw the book at them.
Please read this response.
> Because there's absolutely no business reason why
> Microsoft would care to support such a standard?
The adapter I'm describing requires nothing from the OS vendor. Yes, someone will still have to code the OS specific adapter code, but that's not necessarily the vendor. Once completed, the adapter would plug in like a normal driver and all Cross Platform drivers would plug into the adapter.
For quite a while now, I've considered what sorts of problems would be inherent in cross platform drivers. Usually, the problem seems to come back to a difference in the way kernels manage their drivers and differences in the way that I/O is done between OSes. Perhaps a "Driver Adapter" could be built that would allow drivers written for it to run on any OS? The basic concept is that the adapter itself would be a driver for the OS, then the "Cross Platform Drivers" would deal directly with the adapter.
Anyone have any thoughts on why this would or wouldn't work?
Okay 32,768 colors. So sue me. :-) Since most games were very cartoony in nature, it wasn't usually obvious that the screen was palette swapping. And IIRC, the more advanced scaling and rotation stuff was called "Mode 7" or something like that. The first game to show it off was the second game released for the SNES: the psuedo 3D "Pilot Wings".
Ah, memories. Of course, with hit titles like "Sim City", "TMNT 4", "Street Fighter 2", "Contra III", "F-Zero" and "Zelda 3: A Link to the Past", the SNES was a shoe in.
Actually, the processors in home consoles have traditionally sucked. What makes them useful (and impressive) is the video hardware that does all the work. Let's take the Super Nintendo as an example. This machine could barely manage a few megahertz, yet it was scaling/rotating/blitting out hi-res graphics with millions of colors. How did it do it? Well, there was Sprite based hardware that could take a section of memory and generate a video overlay signal directly off that memory. The processor simply had to say "move it here" or "scale it by this much" and the hardware did it. There was no "blitting" as we think of it on PCs.
Of course, this meant the hardware was limited to the maximum number of sprites that could be handled in hardware at a given time. In fact, You may have noticed an artifact of this approach when too many sprites got on the screen and all the characters started flickering. Still, the results were impressive and PCs couldn't hold a candle.
Now, when 3D graphics came along, PCs (for the first time ever) ended up using the same video hardware as consoles. Consoles still had some advantages in the area of special optimizations and platform consistency, but the performance gap was narrowing.
What do we have today? PCs dressed up like consoles. (i.e. XBox)
> I thought that the Athlon 64 and Opteron were
> currently limited to 48 bits of address space, for
> packaging reasons?
The design can address 64 bits. It's physical ability to support memory is limited by the motherboard. For example, the Intel Pentium architecture can address 4 gigs, but consumer motherboards tend to have maximums of 512MB to 2Gigs.
Dare I mention EMM386 and Himem.sys? Or the LIM (Lotus, Intel, Microsoft) specification? Or the 286 mode and triple faulting? Or -
...
You know, now that I think about it, it's a wonder I didn't hate computers back then.
>> The current definition of a 64 bit processor is one that
>> can use 64 bit memory addressing.
>
>So.. a processor that can understand 64-bit numbers.
Do you have any idea what "64 bit memory addressing" means? It doesn't mean math. It means "more pigeon holes to put stuff in". There are two things stopping modern processors from going to 64 bit addressing:
1. Comatibility
2. More complex and expensive memory controllers, motherboards, bus designs, etc.
The silicon on the chip is the least of our concerns.
> (This was before the days of on-board video memory.)
:-)
Incorrect. EGA and VGA cards had onboard memory that was *mapped* to the A000 and B000 ranges. That memory was reserved because IBM didn't want to deal with direct I/O port communications in software. The only part that sucked was that they used so much memory. I mean really, did they need to whole B000 range for text mode graphics? And why couldn't we use the same memory for graphics and text?
Of course, some memory extenders would try to detect what video mode you were in and make use of the extra memory.
Welcome to Linux hell. You might try a Solaris or FreeBSD installation.
*ducks*
> c'mon now, they just shipped you free water, and you're
> complaining?!
Two words: Wall Drug
a 32 bit machine working on 64 bit numbers involves multiple iterations of the same units... obviously a computer can work on arbitrary sized bit fields.. it can do 900 bit math, too.....
but at it's heart, it's doing 32 bit stuff.
Not true. Most modern processors have silicon dedicated to processing 64 bit numbers. In fact, most processors can do 128 bit numbers thanks to SMID instructions (e.g. SSE, 3DNow, Altivec, etc.)
The current definition of a 64 bit processor is one that can use 64 bit memory addressing.
> Hum, seems like several companies have handled the
> memory issue. How the heck are they getting away with
> 64GIGS of memory on some of these 32bit servers?
It's called segmented memory. Remember the old DOS days when programs couldn't address more than 64K of memory without adding special "Large Model" addressing? Well it's baaaackkk! No program can access more than 4 gigs of RAM without being compiled specifically to bank switch. Thus, you can have multiple programs that can all run with up to 4 gigs of RAM, but none of those programs will be able to process more data than that. 64 bit processors make this easy by allowing flat addressing of >4Gigs. Just like how 32bit processors allowed addressing of >1024K (minus the ~300K that IBM "reserved").
> And did you know AMD is sending free amd64 arch
> manuals (4 nice books) freely to anyone in US and
> Canada? Did you?
Did you know that Intel had free manuals years before the AMD64 was introduced? Did you!? And did you know that they are NICE manuals that are carefully packed, unlike my AMD64 manuals which are flimsy and arrived with water damage? Did you!?
Yes, that's the REAL issue for switching. The REAL issue for time is simply to get programs to switch over to using 64 bit time APIs. Nothing to do with 64/32 bit processors. Sorry if I was confusing on that point.
I'm not in a hurry to ditch any of my 32-bit machines, so long as I get them replaced by 2038.
I hope the editors realize that 32bit processors CAN process 64 bit numbers. In Java, for example, the date is handled by a 64bit number that tells the number of milliseconds since Jan 1, 1970. Amazingly enough, that clock won't run out for another few billion years.
Oh, and most Unixes have fixed the time problem. The real issue is getting the programs to switch over to the new APIs.
> Does PostgreSQL have a good GUI component for direct database manipulation?
Traditionally, this has been the job of third party developers. SQL Server is the one exception as it tries to make you dependent on the GUI tools. Still, if you want a GUI tool, both pgAdmin and my own DataDino are good alternatives.
> The alternatives being ssh and using the DB's shell or some client GUI tool
You forgot about the advantage of not leaving the database port open to the internet. Many databases are rather lax when it comes to security, simply assuming that you'll keep them behind a firewall. Despite that, I know of quite a few people who use DataDino over dial-up. Having a full blown GUI tool gives them a lot of flexibility, but you have to wonder how safe it is.
Of course, that's assuming that anyone wants your data to begin with...
Sorry for the self-promotion, but you might give DataDino a try. It should do everything you need WITHOUT requiring you to compile and install every ODBC driver yourself (a big problem on OS X).
Well, I suppose it doesn't have the Excel thing, but you could put in an enhancement request...
No argument here. My only point was that we can't just send it "floating off" into deep space and hope it takes some good pictures. The Hubble isn't properly equipped nor do we have off the shelf equipment that could perform the task for the Hubble. Either they've got to service it or deorbit it. Both options would tend to equate to a stop over of the shuttle or some other automated satellite. The one other option is an explosive missile, but that tends to add more space junk in the skies.