>...COBOL, which I am currently using to develop...
You get to use COBOL? Lucky bastard! I'm stuck with ones and zeros, and I had to fight to get the ones. Once I had to write an entire database with just zeros.
> I wonder if it would be possible to rip of the IDE controller board from a hard disk and replace it with a SCSI one
I've been dreaming of this for years. The problem is the different natures of IDE and SCSI tech. I'm no expert, but IDE seems to depend on constant attention from the CPU. That means the the converter would have to include a stand-alone microprocessor and memory to handle the IDE controller, plus the SCSI controller to talk to the bus. A single-chip 486 with IDE and SCSI running some ultra-hacked software would do it, but there's no way it'd be cost effective.
On the bright side, you could map multiple IDE drives into a single SCSI ID (2 per IDE channel). A standard dual controller could handle 4 drives, but the SCSI bus would only see one ID. Might make for an amusing RAID/mirroring solution.
>...quit or click on the disasters menu and select all of them. I'm glad bill decided to step back...
AHA! It all makes sense now! Just think: - MS Bob - Netscape, the Internet in general - laughable MS defense during trial(s) - rise of open software
Bill *has* been clicking everything on the SimCorp disaster menu, stirring up every kind of trouble he can think of. World domination wasn't as fun as he thought, so he's trying to end the game. Problem is, his peons are too clever and keep working around it. Nothing seems to stop them.
I'm figuring that right about now his cursor is hovering around "Stock Market Adjustment". If that doesn't work he'll be forced to develop thermonuclear weapons.
Microsoft(r) Nuke(tm) V1.0 -- Guaranteed to go down in flames!
The authority citation for part 734 continues to read as follows: Authority: 50 U.S.C. app. 2401 et seq.; 50 U.S.C. 1701 et seq.; E.O. 12924, 59 FR 43437, 3 CFR, 1994 Comp., p. 917; E.O. 12938, 59 FR 59099, 3 CFR, 1996 Comp. p. 219; E.O. 13026, 61 FR 58767, 3 CFR, 1996 Comp., p. 228;...
Do you have sensitive data that could fall into the wrong hands? Need to restrict access to authorized users only? Has the access to information act forced you to publicly release documents that you'd prefer to keep hidden? Well, your worries are over!
NEW! Security Through Obscurity: legalese edition. Keeping peons out of the legal process.
I am surprised. I didn't know that you could easily develop libraries for Linux that can mimic the win32, macOS, os2 and palm APIs. Perhaps you should publish this wonderful emulation library you have! Put MS *and* Apple out of business! </sarcasm>
I agree that it is possible to create a cross-platform portability library to allow you to use a single platform for most of your development. This is the _Right_Thing_To_Do_(tm). This library, however, needs to be written and maintained. That means you need to build, test, and debug on all your target configurations before you can develop your application from your favorite desktop.
This isn't too bad assuming you're writing a middle-level application -- text based, mostly ANSI C stuff. Once you start into high-level you need to deal with the intricacies of particular window systems; you really have to deal with the actual target. The same holds at the very low-level (where I live). Just because I can cross-assemble ARM or PPC code on a x86 machine doesn't mean I'll get the calling convention right.
The reality of cross-platform software development isn't development, it's debugging. There's always something that runs on A but not on B, no matter how portable your code seems. When that happens, you have no choice but to fire up the debugger on B and figure it out. The harsh truth is most debuggers suck badly, and most of them are radically different.
What I'm really ranting about is the lack of good debugging tools. If debugging is neurosurgery; the debugger our scalpel. WinDbg is sharp but the blade breaks off a lot. Gdb is a 2-handed battle axe -- cuts well but it's not great for fine work. Most of the rest range from butter knives to plastic sporks to rubber mallets.
I don't really want an IDE. I'll put up with a dozen different compilers and various implementations of make. I just want a good debugging story with a powerful and extensible visual front end that handles assembler source and has useful conditional breakpoints; coupled with a remote back-end that runs on every CPU and OS.
That and flying pigs, honest politicians, and cold fusion.
Simple question, simple answer: cross platform development. It may surprise you to learn that there are other platforms in the world than Linux.
If you're developing for more than one target a consistent editor/compiler/debugger story is a huge win. I'd give up several important parts of my anatomy to have something like Microsoft's WinDbg debugger (the one that comes with the NT SDK) on all the platforms I have to deal with. Instead I'm stuck with a powerful winnt/x86 debugger, a couple of variants of gdb and dbx (moderately useful, no assembler source) and a handful of even stranger (barely useful) tools for other OS/CPU configurations.
Getting rid of the mental context switch between two or more toolsets is well worth 300 bucks. A powerful tool that works everywhere you work is priceless.
The fundamental flaw with this famous thought experiment is the use of a cat. As everyone knows, cats are born with nine lives. Assuming a random distribution of cat-deaths, a random chosen cat would be expected to have 4.5 lives remaining. Therefore, the cat in question almost certainly has enough lives to survive the experiment, regardless of the outcome. In addition, the cat's natural curiosity is likely to classify it as a quantum observer, thereby collapsing the state-vector and ruining the experiment.
To rectify these problems, I propose that this experiment henceforth be refered to as "Schrodinger's slug".
I think you're on the wrong track. As far as I can tell from their low-content website ALL the work happens on the remote machine and only the display info is passed back over the net. For example, this means that you use the X server on the remote machine, not on the local machine (as you normally would). Your Mesa library wouldn't be used since your machine wouldn't be rendering OpenGL -- only raw display data.
Their server wouldn't have to be on the same order of magic as VMWare. They would hook display events, render the image, and send it to the client. Likewise they'd hook the input mechanism (keyboard/mouse) to read from the client instead of the hardware. Really, it's not conceptually any different than a telnet server.
As for running something like Quake, I would expect one of the following to happen if you tried to run Q3A: (actually, Q3A is a bad example; let's say some DirectX game that's actually friendly to Windows) (1) nothing happens because their product can't eat full-screen display events (2) the game runs nicely on the window machine, and the 60 frames per second (or whatever) worth of updates are streamed across the network to your linux box causing the worst lag ever.
Unless they're doing something really clever (they're probably doing something clever, but not REALLY clever -- their executable is too small) running a video-intensive app is going to suck. Consider a simple case: 1024x768 resolution, 16 bit colour (= 2 bytes/pixel) at 60 frames per second. That's 1024*768*2*60 = 94,371,840 bytes = 90MB of video data per second. Do you have 720Mbps of network bandwidth to waste? Didn't think so.
For a standard business/web type app you don't have the same problem because you have a smaller data set that changes far less often. Pounding keys as fast as I possibly can results in about 30-40 characters per second. 60fps is overkill, 6 would be fine. What's more, only a small part of the screen is actually being drawn to (just one line in this case).
Of course, I'm talking out my ass here so feel free to ignore me.
Chances are this has absolutely nothing to do with the PSII. A quick bit of research shows that Sony stock has been climbing steadily from ~65 to ~270 over the past year (over 300% gain...wish I owned some!).
$270 per share is generally considered "high", so the stock is split. Theoretically a split has no effect on the company's value (2*135 == 1*270); in practice this tactic increases the volume of trading and usually creates the illusion of increased value.
Re:Random RISC OS trivia by an ex-user
on
The ROX Desktop
·
· Score: 3
The other thing RISC OS got really really right was its application encapsulation. That is, you have a directory which contains the main program binary, an initialisation script, any other program-specific resources, plus an icon for the Filer to display.
They're not the only ones to ever have this idea.
This sounds identical to the NeXT/OPENSTEP/OS X.app format that's been around since the 1980's: a directory that contains the executable and support files (such as data files, graphics, the interface description (.nib files), locale specific data, and the application's icon) but shows up as a single icon in the UI.
The real beauty of this kind of format is that an application can be treated as a unit: installed, deleted, moved, FTPed, etc. without losing any of the associated files -- so much cleaner than the windows uninstall mechanism, or poking through/usr/lib and/usr/bin for that matter.
>...much of the investment is from power companies. Gee, wonder why they are so interested
Three words: "covering their asses".
For a big power company a couple of million is pocket change. There is a slim but non-zero chance that this might be real. There's a much higher chance that something interesting will come of his work -- probably totally unrelated to the "limitless cheap clean y2k compliant linux compatible energy" claims. Perhaps a new material or process, maybe even a new theory or an amendment to an existing one. Worst case scenario they lose their investment, but can point to the incident as an example of how open-minded and progressive they are, and how eager they are to move away from the mediapathic planet-destroying technology that they're *forced* use today. Good press is a valuable commodity.
>Can you imagine the privacy issues that would go along with wide use of this technology?
Sure I can. I'd be someting like this: "OK, he's moving the cursor left and up." "Looks like he's heading for the icons." "My god! He's clicking on `The Internet'!"
This is little more than a limb replacement. Even a full-blown sci-fi version would only replace your current interface (keyboard/mouse/video/sound). Tapping that kind of information is already possible: binoculars and a parabolic microphone would do it; or Tempest for the hard-core.
Just relax. The government probably doesn't care about your thoughts anyway.
Massively parallel machines tend not to "run" an OS as much as they are "run by" an OS. The control nodes or stations (often separate machines) run whatever (i.e. Unix) and the actual compute nodes run their computation and little else. After all, running 10000 copies of Linux isn't really the best use of resources.
The fireworks may not be US missiles, but that doesn't mean that we won't get nuked.
While I don't really expect anything THAT nasty to happen, it's pure crap to suggest that everything will be fine because the US thinks they have their act together. The global system as it stands is so heavily integrated that an oops in one part of the world will likely have a serious impact on everyone else. The recent Asian market crash should have made that quite clear.
> as the "32" suggests, don't support a 64-bit flat address space
My point was that their code was already architected for both memory models (can you say "#ifdef"? I knew you could).
As for the instruction set, take a quick look at the site. They emphasize backwards compatibility with existing Solaris x86 binaries. They probably only "ported" the essentials (memory manager, program loader, etc.) and ran everything else in IA32 compatibility mode.
For a commercial system like Solaris, the backwards compatibility is more interesting than anything else. Remember, IS manager types are easily spooked. Demoing a mix of IA-32 and -64 binaries would be in their favor.
Hmmm...lets see... Solaris/UltraSparc is 64 bit; IA64 supports IA32 instructions. Why am I not surprised that they managed to get this to run. It's still a good thing, though.
Anyway, the real question is: "what's the critical mass of itantium". Is it fissionable?
I think that an important point has been overlooked here. With the recent release of Windows NT Embedded 4.0, MS already has a "new" OS to deploy on this kind of platform. Who wants WinCE when you can have NT?
If they intend to continue the CE line after EmbeddedNT is fully under way, they're going to need a hook to get (and keep) people interested. Free (gratis) worked for IE, free (libre) might help CE.
>What happens if you abort the launch before the rocket ignites?
Not too big a deal. If the vehicle is still on the track, the same process can be used to slow it down (flip the polarity).
If that's not an option (more than 50% of the track used) then you just continue the launch. The vehicle would have to have a reentry mode -- just have a recovery site strategically placed at the end of the trajectory. For a shuttle-style vehicle, this could just be a modified airfield. For a "one-shot" vehicle, the ocean works great.
Several years back I remember hearing that the FBI was taking some heat over the fact that their conviction rate for computer crimes was practically zero, despite numerous (well, numerous for the time) arrests. You do the math.
It's probably less prevalent now, since the average perp they catch is likely a 12 year old with BO2K and a bag of scripts. Not exactly spook material.
Slashdot Mirror
>...COBOL, which I am currently using to develop...
You get to use COBOL? Lucky bastard! I'm stuck with ones and zeros, and I had to fight to get the ones.
Once I had to write an entire database with just zeros.
> I wonder if it would be possible to rip of the IDE controller board from a hard disk and replace it with a SCSI one
I've been dreaming of this for years. The problem is the different natures of IDE and SCSI tech. I'm no expert, but IDE seems to depend on constant attention from the CPU. That means the the converter would have to include a stand-alone microprocessor and memory to handle the IDE controller, plus the SCSI controller to talk to the bus. A single-chip 486 with IDE and SCSI running some ultra-hacked software would do it, but there's no way it'd be cost effective.
On the bright side, you could map multiple IDE drives into a single SCSI ID (2 per IDE channel). A standard dual controller could handle 4 drives, but the SCSI bus would only see one ID. Might make for an amusing RAID/mirroring solution.
The people who really benefit from high clock speeds are the 3Dgamers. AFAIK there aren't any games that take advantage of SMP.
ID was looking into it, but I don't believe they shipped the hacks with Q3A. Anyone know what happened with this?
>...quit or click on the disasters menu and select all of them. I'm glad bill decided to step back...
AHA! It all makes sense now! Just think:
- MS Bob
- Netscape, the Internet in general
- laughable MS defense during trial(s)
- rise of open software
Bill *has* been clicking everything on the SimCorp disaster menu, stirring up every kind of trouble he can think of. World domination wasn't as fun as he thought, so he's trying to end the game. Problem is, his peons are too clever and keep working around it. Nothing seems to stop them.
I'm figuring that right about now his cursor is hovering around "Stock Market Adjustment". If that doesn't work he'll be forced to develop thermonuclear weapons.
Microsoft(r) Nuke(tm) V1.0 -- Guaranteed to go down in flames!
Authority: 50 U.S.C. app. 2401 et seq.; 50 U.S.C. 1701 et seq.; E.O. 12924, 59 FR 43437, 3 CFR, 1994 Comp., p. 917; E.O. 12938, 59 FR 59099, 3 CFR, 1996 Comp. p. 219; E.O. 13026, 61 FR 58767, 3 CFR, 1996 Comp., p. 228;
Do you have sensitive data that could fall into the wrong hands? Need to restrict access to authorized users only? Has the access to information act forced you to publicly release documents that you'd prefer to keep hidden? Well, your worries are over!
NEW! Security Through Obscurity: legalese edition.
Keeping peons out of the legal process.
I am surprised. I didn't know that you could easily develop libraries for Linux that can mimic the win32, macOS, os2 and palm APIs. Perhaps you should publish this wonderful emulation library you have! Put MS *and* Apple out of business!
</sarcasm>
I agree that it is possible to create a cross-platform portability library to allow you to use a single platform for most of your development. This is the _Right_Thing_To_Do_(tm). This library, however, needs to be written and maintained. That means you need to build, test, and debug on all your target configurations before you can develop your application from your favorite desktop.
This isn't too bad assuming you're writing a middle-level application -- text based, mostly ANSI C stuff. Once you start into high-level you need to deal with the intricacies of particular window systems; you really have to deal with the actual target. The same holds at the very low-level (where I live). Just because I can cross-assemble ARM or PPC code on a x86 machine doesn't mean I'll get the calling convention right.
The reality of cross-platform software development isn't development, it's debugging. There's always something that runs on A but not on B, no matter how portable your code seems. When that happens, you have no choice but to fire up the debugger on B and figure it out. The harsh truth is most debuggers suck badly, and most of them are radically different.
What I'm really ranting about is the lack of good debugging tools. If debugging is neurosurgery; the debugger our scalpel. WinDbg is sharp but the blade breaks off a lot. Gdb is a 2-handed battle axe -- cuts well but it's not great for fine work. Most of the rest range from butter knives to plastic sporks to rubber mallets.
I don't really want an IDE. I'll put up with a dozen different compilers and various implementations of make. I just want a good debugging story with a powerful and extensible visual front end that handles assembler source and has useful conditional breakpoints; coupled with a remote back-end that runs on every CPU and OS.
That and flying pigs, honest politicians, and cold fusion.
Simple question, simple answer: cross platform development. It may surprise you to learn that there are other platforms in the world than Linux.
If you're developing for more than one target a consistent editor/compiler/debugger story is a huge win. I'd give up several important parts of my anatomy to have something like Microsoft's WinDbg debugger (the one that comes with the NT SDK) on all the platforms I have to deal with. Instead I'm stuck with a powerful winnt/x86 debugger, a couple of variants of gdb and dbx (moderately useful, no assembler source) and a handful of even stranger (barely useful) tools for other OS/CPU configurations.
Getting rid of the mental context switch between two or more toolsets is well worth 300 bucks. A powerful tool that works everywhere you work is priceless.
The fundamental flaw with this famous thought experiment is the use of a cat. As everyone knows, cats are born with nine lives. Assuming a random distribution of cat-deaths, a random chosen cat would be expected to have 4.5 lives remaining. Therefore, the cat in question almost certainly has enough lives to survive the experiment, regardless of the outcome. In addition, the cat's natural curiosity is likely to classify it as a quantum observer, thereby collapsing the state-vector and ruining the experiment.
To rectify these problems, I propose that this experiment henceforth be refered to as "Schrodinger's slug".
I think you're on the wrong track. As far as I can tell from their low-content website ALL the work happens on the remote machine and only the display info is passed back over the net. For example, this means that you use the X server on the remote machine, not on the local machine (as you normally would). Your Mesa library wouldn't be used since your machine wouldn't be rendering OpenGL -- only raw display data.
Their server wouldn't have to be on the same order of magic as VMWare. They would hook display events, render the image, and send it to the client. Likewise they'd hook the input mechanism (keyboard/mouse) to read from the client instead of the hardware. Really, it's not conceptually any different than a telnet server.
As for running something like Quake, I would expect one of the following to happen if you tried to run Q3A: (actually, Q3A is a bad example; let's say some DirectX game that's actually friendly to Windows)
(1) nothing happens because their product can't eat full-screen display events
(2) the game runs nicely on the window machine, and the 60 frames per second (or whatever) worth of updates are streamed across the network to your linux box causing the worst lag ever.
Unless they're doing something really clever (they're probably doing something clever, but not REALLY clever -- their executable is too small) running a video-intensive app is going to suck. Consider a simple case: 1024x768 resolution, 16 bit colour (= 2 bytes/pixel) at 60 frames per second. That's 1024*768*2*60 = 94,371,840 bytes = 90MB of video data per second. Do you have 720Mbps of network bandwidth to waste? Didn't think so.
For a standard business/web type app you don't have the same problem because you have a smaller data set that changes far less often. Pounding keys as fast as I possibly can results in about 30-40 characters per second. 60fps is overkill, 6 would be fine. What's more, only a small part of the screen is actually being drawn to (just one line in this case).
Of course, I'm talking out my ass here so feel free to ignore me.
$270 per share is generally considered "high", so the stock is split. Theoretically a split has no effect on the company's value (2*135 == 1*270); in practice this tactic increases the volume of trading and usually creates the illusion of increased value.
They're not the only ones to ever have this idea.
This sounds identical to the NeXT/OPENSTEP/OS X .app format that's been around since the 1980's: a directory that contains the executable and support files (such as data files, graphics, the interface description (.nib files), locale specific data, and the application's icon) but shows up as a single icon in the UI.
The real beauty of this kind of format is that an application can be treated as a unit: installed, deleted, moved, FTPed, etc. without losing any of the associated files -- so much cleaner than the windows uninstall mechanism, or poking through /usr/lib and /usr/bin for that matter.
But don't mind me, I'm just a bitter NeXT bigot.
> ...much of the investment is from power companies. Gee, wonder why they are so interested
Three words: "covering their asses".
For a big power company a couple of million is pocket change. There is a slim but non-zero chance that this might be real. There's a much higher chance that something interesting will come of his work -- probably totally unrelated to the "limitless cheap clean y2k compliant linux compatible energy" claims. Perhaps a new material or process, maybe even a new theory or an amendment to an existing one. Worst case scenario they lose their investment, but can point to the incident as an example of how open-minded and progressive they are, and how eager they are to move away from the mediapathic planet-destroying technology that they're *forced* use today. Good press is a valuable commodity.
It's a WIN-Win-win situation at a low, low price.
>Can you imagine the privacy issues that would go along with wide use of this technology?
Sure I can. I'd be someting like this:
"OK, he's moving the cursor left and up."
"Looks like he's heading for the icons."
"My god! He's clicking on `The Internet'!"
This is little more than a limb replacement. Even a full-blown sci-fi version would only replace your current interface (keyboard/mouse/video/sound). Tapping that kind of information is already possible: binoculars and a parabolic microphone would do it; or Tempest for the hard-core.
Just relax. The government probably doesn't care about your thoughts anyway.
Not to disagree with the basic point (journalists are yahoos) but don't most gas giants radiate slightly more energy than they receive?
Please tell me I'm not the only one thinking "electric monk" (or, in this case, iMonk).
Massively parallel machines tend not to "run" an OS as much as they are "run by" an OS. The control nodes or stations (often separate machines) run whatever (i.e. Unix) and the actual compute nodes run their computation and little else. After all, running 10000 copies of Linux isn't really the best use of resources.
>New Year's fireworks won't be misfired missiles
The fireworks may not be US missiles, but that doesn't mean that we won't get nuked.
While I don't really expect anything THAT nasty to happen, it's pure crap to suggest that everything will be fine because the US thinks they have their act together. The global system as it stands is so heavily integrated that an oops in one part of the world will likely have a serious impact on everyone else. The recent Asian market crash should have made that quite clear.
Sigh.
>Hmmm... that probably explains The Doctor's scarf.
Ok, I've heard watches, sleeves, and now a scarf. Everyone's missing the obvious future direction of powerful, portable computers.
Towels.
> as the "32" suggests, don't support a 64-bit flat address space
My point was that their code was already architected for both memory models (can you say "#ifdef"? I knew you could).
As for the instruction set, take a quick look at the site. They emphasize backwards compatibility with existing Solaris x86 binaries. They probably only "ported" the essentials (memory manager, program loader, etc.) and ran everything else in IA32 compatibility mode.
For a commercial system like Solaris, the backwards compatibility is more interesting than anything else. Remember, IS manager types are easily spooked. Demoing a mix of IA-32 and -64 binaries would be in their favor.
Hmmm...lets see... Solaris/UltraSparc is 64 bit; IA64 supports IA32 instructions. Why am I not surprised that they managed to get this to run. It's still a good thing, though.
Anyway, the real question is: "what's the critical mass of itantium". Is it fissionable?
I think that an important point has been overlooked here. With the recent release of Windows NT Embedded 4.0, MS already has a "new" OS to deploy on this kind of platform. Who wants WinCE when you can have NT?
If they intend to continue the CE line after EmbeddedNT is fully under way, they're going to need a hook to get (and keep) people interested. Free (gratis) worked for IE, free (libre) might help CE.
The sad part about this is that they've finally made a 68000 processor run at a faster clock than the 68040 in my NeXTstation.
What's next? 80286DX6's running at 100MHz?
I can hear the marketing slogans already:
"Solve tomorrow's problems with yesterday's technology...today!"
>What happens if you abort the launch before the rocket ignites?
Not too big a deal. If the vehicle is still on the track, the same process can be used to slow it down (flip the polarity).
If that's not an option (more than 50% of the track used) then you just continue the launch. The vehicle would have to have a reentry mode -- just have a recovery site strategically placed at the end of the trajectory. For a shuttle-style vehicle, this could just be a modified airfield. For a "one-shot" vehicle, the ocean works great.
>I wonder what a beowulf of black holes would do?
Don't even bother thinking about it. It would *really* suck.
(sorry...I couldn't resist)
Several years back I remember hearing that the FBI was taking some heat over the fact that their conviction rate for computer crimes was practically zero, despite numerous (well, numerous for the time) arrests. You do the math.
It's probably less prevalent now, since the average perp they catch is likely a 12 year old with BO2K and a bag of scripts. Not exactly spook material.