This doesn't make any sense in the context of audio, though. In the context of audio work, as *long* as things are being done in realtime, at a minimum, then you're alright. I'm speaking purely from a professional musicians perspective - not a compsci/compmus type researcher or engineer - because I believe that is the stance from which this article was originally posited.
Offline faster-than-realtime rendering of audio is typically not all that useful, since audio is a linear medium that must be perceived serially.
It is useful as a backend process - calculating reverb tails and filters, when designing a realtime DSP engine, really does benefit from faster-than-realtime processing, but it doesn't matter to the end user how fast it's done, as long as it sounds the way its supposed to sound when we listen to it in realtime.
You very rarely get a scenario where you're listening to how your compression sounds by 'skipping through the audio' in non-1:1 ratio's - at least, in my experience, this hasn't been very useful...:)
As *long* as the results are done in realtime, we're cool. And as long as the architecture supports realtime results, we're also cool.
So in my scenario, having the Linux "DSP FX boxes" accessible with realtime mLAN-type networking is acceptable and workable.
The typical musician usually just wants to add *more* effects to his mix, not more *complicated* effects (at least not in the midst of production of a track - in experimental mode, yes, sure, give me all the weird granular effects I can handle, but when the time comes to refine a track, I'll stick with what I know so far...), and thus being able to quickly and easily do this by adding a $600 P3box with mLAN/Linux support any time he wants to would be a productive architecture.
And this is what mLAN will give us, ultimately. The day may come when the average musician points at a rack of blinking lights and go "that's my PC-based effects farm, I add to it by buying cheap PC's and I get more effects busses instantly over mLAN"... I look forward to it.
mLAN stands for "musical LAN", which is exactly what it sounds like. There is no point us re-engineering this for Linux, we simply need to work on making Linux a good platform for mLAN development, and we'll get to the point where we can route audio just like we route IP, and thus do things to it just like we do with the content fields of IP packets...
If you want realtime DSP-rendering farms based on Linux, then keep an eye on the work being done to add Firewire/IEEE1394 support to the Kernel. This is where it will start.
... before MP4-SA can begin to function, and I mean *function* in a professional studio in lieu of MIDI.
There's a lot to say about MIDI - sure, it's slow, sure it's limited, but as far as serial control protocols go, it has *definitely* weathered the test of time.
Anyway, this slashdot article is not a problem of MIDI, but a problem of i/o architectures.
The problem with realtime Cubase effects is that they're still very processor/architecture/OS bound. There's no functional way of getting data in and out of a Cubase effects module other than by using the strict architecture path that the effects software has been written to use - this problem exists for Cubase plugins, ProTools/TDM plugins, DirectX plugins, etc.
A better alternative to investing energy into the MP4-SA side of things (which is not a new technology - for a similar example, check out Thomas Dolby's Beatnik, which is a fairly similar implementation) is to instead investigate Linux' support for mLAN, which is Yamaha's "musical LAN" protocol that sits on top of Firewire/IEE1394.
mLAN is the solution to this article's stated problem.
By adding really good support for mLAN in Linux, it's really *NOT* unreasonable to say that Linux clusted boxes could be used for REALTIME DSP processing tasks. mLAN represents audio, video and media-data as individual streams on the same wire - a very good implementation of mLAN/Firewire in the Linux kernel would allow you to separate these streams, route them off to different processes/processors, and stick them back on the mLAN wire in realtime.
This will happen in the PC world.
There are already Windows-based realtime DSP effects boxes that use mLAN as the routing interface, currently in *development* by a number of large music companies (I can't drop names here, I'm under very tight NDA).
With good Firewire support, Linux (and other OSS OS'es) can keep up with these developments, which will hit the market, I'd predict, by Q3 2001. Put the audio out on the wire, route it wherever you want to route it, and get it back off the wire, and we'll never have these limited 'plugin' problems again... which, by the way, is one of the reasons I'm a very strong advocate of musicians *staying* in the hardware realm for now, and leaving the software plugins alone.
The audio world has *ALWAYS* been about interoperability, open specifications, and shared protocols. MIDI would never have come so far, and given us so much, if it weren't for the fact that hardware manufacturers took the time to figure out good ways to work together, in spite of competition. Audio effects architectures have always been very well documented - the average professional mixing desk has been designed from the ground up to be able to work with gear from *all* sorts of manufacturers, using simple protocols and specifications for audio signal routing. (XLR, balanced, etc)
This changed recently with the advent of software plugins, where hardly *ANY* companies are truly working with others to build a common platform - Oh sure, Digidesign have their TDM system, as do Microsoft, as do Steinberg, but pretty much all of these systems were developed from the ground up to be proprietary and to be used in giving 'market edge' to the respective owners.
Next year, software plugins won't be as badly implemented, and the audio world will actually be able to work cooperatively again... because of mLAN.
So, we should work on getting good mLAN/Firewire support in Linux, and develop open API's to solve the problem. Then you can build your Linux audio-rendering farm, hook it all up with mLAN, and forget about proprietary crappy interfaces for your audio work in the future...
Re:.NET might be very good to us
on
Perl and .NET
·
· Score: 1
That was his point. The differences are narrower...
When you get home at night, and you MOTAS/roomies ask how your day was, do you
A. Draw pictures and icons of how your day went.
B. Tell them in words how it went.
You do both.
You draw a picture of the events in your head, and sequence along as you go. And then you describe the pictures of each step in that sequence in words. If your friend doesn't get it, you back up and use other words, until finally the message has made it across space and time to the other side. Sometimes, you might even fall back to drawing a picture - certainly, this is how most linguists worked when encountering foreign members of other races, and it's an effective process of achieving communication, when needed.
Words function as a means of communicating significances and concepts. Pictures also function as a means of communicating significances and concepts.
They are not mutually exclusive of each other, and usually the better computer science types, and thus the better programmers, producing quality software, can function with either communications methodologies just fine.
It's the guys that get stuck on one method, and one method only, that produce crap software...
In the area where this thing is installed, there'd be less splashing, and probably less wind - especially if an entire coastline is populated with them.
Who knows what the environmental effect would be? Perhaps the local ecosystem would be less moist, perhaps not...
True though, that there would be *some* impact. But not nearly as bad as say, depleted radioactive fuel that our descendants are going to have to figure out how to handle somewhere down the line...
I'm sick and tired of trying to keep up with the advances in this technology, only to find out that there's always some glitch or gotcha that gets 'figured out' in the next generation of components.
Frankly, I don't give a crap about mHZ ratings or benchmarks any more. From now on I'm going to base my component-buying decisions on whether or not the company is *honest* about the problems with its product lines, and whether or not they fix them, standardize on ways to do things that won't isolate existing customers when newer revisions become available, etc.
Right now I have an AMD 750 CPU in my main development system which runs just great. It's not the fastest computer I've ever used, but it is *plenty* fast, and I probably won't need to upgrade it for at least another year (hopefully).
I also have a Mac G4, which, for as much as I've despised Apple for Mac OS9.0, is a really, really terrific architecture. Sure, it's not a dual-proc machine, but it is *fast*, and it's *EASY* to upgrade.
Being a long-time computer geek, I've come to appreciate this simplicity of Apple gear more and more - to the point where the x86 way of life is really just too frustrating. Give me Mac OX X on a fast and well-designed G4, sitting in an *available* (i.e. non vaporware mobo) architecture, with sufficient RAM bandwidth and i/o options (Firewire rocks serious ass), and I'm happy.
From now on, Intel are the last CPU mfr's on my list to pay attention to... I'm so tired of being fed a turd while being told it's chocolate.
By default, upon a STOP error (blue screen of death), only the first 640K of RAM is dumped, and the system is automatically restarted (not like NT4, where all RAM was dumped and the system would stay at the BSOD until the user restarted). This can be changed to your liking, but 2000 usually only goes to the BSOD when running corrupt programs
HOW do you change this? I think I have a corrupt video driver on my laptop which causes these crashes, but the damned thing keeps rebooting before I can get to the pause key... care to fill in a clueless W2k user on how to stop W2k from moving past a BSOD too fast?
... the GUI does, but you don't *NEED* to do a reboot to change the IP info.
Use 'winipcfg' to force a refresh on the network card after you've changed your TCP/IP settings (make sure nothing that uses TCP/IP is running, though, this sometimes confuses it), and you can change your settings without needing a full reboot... I do it all the time.
20,000 free valid mailing addresses pointing to security-interested geeks sounds like a mailing list gold mine to me, and probably the marketing genius who thought up the poster idea. A $1000 investment into some nice shiny poster, a couple hundred bucks in postage, and you get a qualified database of hackers you can market to, and also sell to other companies if you feel like it...
Bet we all get spammed with marketing material on security products in the future...
Would it be at all feasible, from a law perspective, to counter-sue Microsoft for *NEGLIGENCE* in protecting their so-called trade secrets?
Wouldn't it be possible to make the argument that since Microsoft *allowed* the source code to get out into the public domain, they are responsible for their own mess, and thus use that as a basis to dismiss any court cases that would be enacted based on this conspiracy theory.
It seems to me that this argument could be made fairly strongly - as is the case with trademarks - if you do not protect it, you do not deserve the right to exclusivity, and thus there would be no basis for damages should the code be 'used' elsewhere?
Can anyone with a strong legal background comment on the feasibility of this issue? It would seem to me that something like this could be argued in any case against Microsoft for this purpose.
Yup. Fuck it, 700mhz is 'lowend'? I have an AMD 700 mhz (non-Duron) that does just fine for my needs, and I never thought it'd be 'lowend' so soon... though maybe the Celeron/Duron aspect of the 'lowend' label makes sense...
Well, okay, I guess I should've explained that a bit further, but I didn't really want to go too off-topic... in the case of one of my NT friends, a decision was made at his company recently to not do an upgrade from NT -> Win2000, but instead go from NT -> Linux for their servers... so, they're feeling a bit fragile right about now.
I don't see any Word screenshots... not that I have any reason to doubt the WINE developers, but it sure would be nice to be able to show the NT bigots in my acquaintance, just to rub salt in their wounds a little...
Not that I enjoy that sort of thing. Oh, what the heck, yes I do.
So, anyone got screenshots? Might be nice to get a big one with KDE or some other Linux-specific background props around it too...
Umm, you need to get a dictionary, you big feminist wanna be, you... you got your feminazi mindbot on automatic, and not actually *reading* the words you think you're reading...
Babe: n. baby.
Baby: defn. 2 (the one that fits), "the youngest of a family or group". defn. 3, "SLANG. plan, idea or project." --adj 1. "young"
So, the use of the word 'babe' in this case is highly appropriate, and actually very, very accurate.
There is no technology available now or forseeable in the future that will make it safe to fly a personal plane into a thunderstorm or into ice. There is no technology that will take away your ability to fly into them. The only technology that can do that is technology that keeps you on ground, always.
"If God had wanted man to fly, he would have given us wings."
"Flying is for the birds, not man."
etc.
What a dope you are. You can't see the sky for the clouds...
I also have a Handspring Visor[Palm], which will evolve into a much more powerful computer, I'm sure of it, and it follows the same policy of using a permanent resident store for all data and applications...
Actually, I believe this is one of the reasons it's such a successful platform - the assumption that all data is always available, and there is no secondary 'commit' stage to offline storage means that the OS can be used a lot more efficiently by the end user...
For that matter, with this sort of technology, using it for offline storage would be moot.
Hard drives are a hack because RAM is so expensive and difficult to maintain without loss (i.e. turn it off, away it goes). With this sort of technology, presumably we'd have a whole new realm of design to consider, such that we don't *need* offline storage (which is what hard drives used to be called) for the CPU to save to in case of power outage.
I look forward to the day when there's just memory, lots of it, it's very fast, and it doesn't require a lot of power to move parts around. *That* will be a computer worth obsessing about...
Fair enough, I do agree with you. Anti-NASA doesn't mean anti-SPACE.
But I often find the anti-NASA sentiment to be completely lacking any fundamental basis in reality, other than membership in the popular lynching culture that so many diletanttes seem to adhere to.
NASA has done a *hell* of a lot for space exploration... and if you take the time to actually peek behind the mud slung on NASA, you'll find an incredible amount of actual, real, hard-core scientific value.
Don't come to me with anti-NASA sentiments unless you've got a pile of NASA Tech Briefs sitting in your basement (like I do), and can refer to articles from 3 years back. Don't come to me with anti-NASA sentiments unless you know your way around the NASA web sites well enough to know how to get the full Apollo manuscripts and audio archives, unless you know the details of STS-33 and the significance it had on space exploration, unless you can tell me what the NBL is.
I don't want to hear your anti-NASA sentiments if you don't even know what NASA is, and what it's been all about all along...
It's an incredibly difficult thing to engineer rotating structures in space and *still* maintain the correct position in space in order to keep orbit.
There *are* rotating structures in the space station - they're called gyro's, and in fact they're used by the station to move around. There are gyro's all over the ISS - spin one up, and the station starts to move in that direction, slowly due to centrifugal force.
They're an efficient means of maintaining position, because they're run by electric (solar) power, and thus don't require expendable fuel like the retro rockets do...
On the last picture that shows the station with Z1 truss... keep in mind that the entire station is *13* stories tall from one end to the other right now.
That might give you a better idea of the scale of the thing.
Slashdot Mirror
Okay, I get the difference you're pointing out.
:)
This doesn't make any sense in the context of audio, though. In the context of audio work, as *long* as things are being done in realtime, at a minimum, then you're alright. I'm speaking purely from a professional musicians perspective - not a compsci/compmus type researcher or engineer - because I believe that is the stance from which this article was originally posited.
Offline faster-than-realtime rendering of audio is typically not all that useful, since audio is a linear medium that must be perceived serially.
It is useful as a backend process - calculating reverb tails and filters, when designing a realtime DSP engine, really does benefit from faster-than-realtime processing, but it doesn't matter to the end user how fast it's done, as long as it sounds the way its supposed to sound when we listen to it in realtime.
You very rarely get a scenario where you're listening to how your compression sounds by 'skipping through the audio' in non-1:1 ratio's - at least, in my experience, this hasn't been very useful...
As *long* as the results are done in realtime, we're cool. And as long as the architecture supports realtime results, we're also cool.
So in my scenario, having the Linux "DSP FX boxes" accessible with realtime mLAN-type networking is acceptable and workable.
The typical musician usually just wants to add *more* effects to his mix, not more *complicated* effects (at least not in the midst of production of a track - in experimental mode, yes, sure, give me all the weird granular effects I can handle, but when the time comes to refine a track, I'll stick with what I know so far...), and thus being able to quickly and easily do this by adding a $600 P3box with mLAN/Linux support any time he wants to would be a productive architecture.
And this is what mLAN will give us, ultimately. The day may come when the average musician points at a rack of blinking lights and go "that's my PC-based effects farm, I add to it by buying cheap PC's and I get more effects busses instantly over mLAN"... I look forward to it.
http://www.yamaha.co.jp/tech/1394mLAN/mlan.html-- detailed mLAN specs.
See here for my earlier comment/response.
Some links to mLAN resources, by no means complete, please follow-up with more URL's if you find them (I don't have time):
Pavo (leader in 3rd party mLAN development): http://www.pavo.com/
Yamaha's mLAN (pretty pictures): http://www.harmony-central.com/Newp/2000/mLAN.html
Details on mLAN products (Japanese) http://www.miroc.co.jp/Tango/qrys/NEWS/yamaha/mlan .html
mLAN stands for "musical LAN", which is exactly what it sounds like. There is no point us re-engineering this for Linux, we simply need to work on making Linux a good platform for mLAN development, and we'll get to the point where we can route audio just like we route IP, and thus do things to it just like we do with the content fields of IP packets...
If you want realtime DSP-rendering farms based on Linux, then keep an eye on the work being done to add Firewire/IEEE1394 support to the Kernel. This is where it will start.
-- Jay Vaughan - jv@teklab.com
... before MP4-SA can begin to function, and I mean *function* in a professional studio in lieu of MIDI.
... which, by the way, is one of the reasons I'm a very strong advocate of musicians *staying* in the hardware realm for now, and leaving the software plugins alone.
There's a lot to say about MIDI - sure, it's slow, sure it's limited, but as far as serial control protocols go, it has *definitely* weathered the test of time.
Anyway, this slashdot article is not a problem of MIDI, but a problem of i/o architectures.
The problem with realtime Cubase effects is that they're still very processor/architecture/OS bound. There's no functional way of getting data in and out of a Cubase effects module other than by using the strict architecture path that the effects software has been written to use - this problem exists for Cubase plugins, ProTools/TDM plugins, DirectX plugins, etc.
A better alternative to investing energy into the MP4-SA side of things (which is not a new technology - for a similar example, check out Thomas Dolby's Beatnik, which is a fairly similar implementation) is to instead investigate Linux' support for mLAN, which is Yamaha's "musical LAN" protocol that sits on top of Firewire/IEE1394.
mLAN is the solution to this article's stated problem.
By adding really good support for mLAN in Linux, it's really *NOT* unreasonable to say that Linux clusted boxes could be used for REALTIME DSP processing tasks. mLAN represents audio, video and media-data as individual streams on the same wire - a very good implementation of mLAN/Firewire in the Linux kernel would allow you to separate these streams, route them off to different processes/processors, and stick them back on the mLAN wire in realtime.
This will happen in the PC world.
There are already Windows-based realtime DSP effects boxes that use mLAN as the routing interface, currently in *development* by a number of large music companies (I can't drop names here, I'm under very tight NDA).
With good Firewire support, Linux (and other OSS OS'es) can keep up with these developments, which will hit the market, I'd predict, by Q3 2001. Put the audio out on the wire, route it wherever you want to route it, and get it back off the wire, and we'll never have these limited 'plugin' problems again
The audio world has *ALWAYS* been about interoperability, open specifications, and shared protocols. MIDI would never have come so far, and given us so much, if it weren't for the fact that hardware manufacturers took the time to figure out good ways to work together, in spite of competition. Audio effects architectures have always been very well documented - the average professional mixing desk has been designed from the ground up to be able to work with gear from *all* sorts of manufacturers, using simple protocols and specifications for audio signal routing. (XLR, balanced, etc)
This changed recently with the advent of software plugins, where hardly *ANY* companies are truly working with others to build a common platform - Oh sure, Digidesign have their TDM system, as do Microsoft, as do Steinberg, but pretty much all of these systems were developed from the ground up to be proprietary and to be used in giving 'market edge' to the respective owners.
Next year, software plugins won't be as badly implemented, and the audio world will actually be able to work cooperatively again... because of mLAN.
So, we should work on getting good mLAN/Firewire support in Linux, and develop open API's to solve the problem. Then you can build your Linux audio-rendering farm, hook it all up with mLAN, and forget about proprietary crappy interfaces for your audio work in the future...
That was his point. The differences are narrower...
A. Draw pictures and icons of how your day went. B. Tell them in words how it went.
You do both.
You draw a picture of the events in your head, and sequence along as you go. And then you describe the pictures of each step in that sequence in words. If your friend doesn't get it, you back up and use other words, until finally the message has made it across space and time to the other side. Sometimes, you might even fall back to drawing a picture - certainly, this is how most linguists worked when encountering foreign members of other races, and it's an effective process of achieving communication, when needed.
Words function as a means of communicating significances and concepts. Pictures also function as a means of communicating significances and concepts.
They are not mutually exclusive of each other, and usually the better computer science types, and thus the better programmers, producing quality software, can function with either communications methodologies just fine.
It's the guys that get stuck on one method, and one method only, that produce crap software...
In the area where this thing is installed, there'd be less splashing, and probably less wind - especially if an entire coastline is populated with them.
...
...
Who knows what the environmental effect would be? Perhaps the local ecosystem would be less moist, perhaps not
True though, that there would be *some* impact. But not nearly as bad as say, depleted radioactive fuel that our descendants are going to have to figure out how to handle somewhere down the line
It lies down in the mud for a few million years, and when asked why, replies:
"It's a wonderful way of being wretched."
Got any references to those articles?
I'm sick and tired of trying to keep up with the advances in this technology, only to find out that there's always some glitch or gotcha that gets 'figured out' in the next generation of components.
Frankly, I don't give a crap about mHZ ratings or benchmarks any more. From now on I'm going to base my component-buying decisions on whether or not the company is *honest* about the problems with its product lines, and whether or not they fix them, standardize on ways to do things that won't isolate existing customers when newer revisions become available, etc.
Right now I have an AMD 750 CPU in my main development system which runs just great. It's not the fastest computer I've ever used, but it is *plenty* fast, and I probably won't need to upgrade it for at least another year (hopefully).
I also have a Mac G4, which, for as much as I've despised Apple for Mac OS9.0, is a really, really terrific architecture. Sure, it's not a dual-proc machine, but it is *fast*, and it's *EASY* to upgrade.
Being a long-time computer geek, I've come to appreciate this simplicity of Apple gear more and more - to the point where the x86 way of life is really just too frustrating. Give me Mac OX X on a fast and well-designed G4, sitting in an *available* (i.e. non vaporware mobo) architecture, with sufficient RAM bandwidth and i/o options (Firewire rocks serious ass), and I'm happy.
From now on, Intel are the last CPU mfr's on my list to pay attention to... I'm so tired of being fed a turd while being told it's chocolate.
By default, upon a STOP error (blue screen of death), only the first 640K of RAM is dumped, and the system is automatically restarted (not like NT4, where all RAM was dumped and the system would stay at the BSOD until the user restarted). This can be changed to your liking, but 2000 usually only goes to the BSOD when running corrupt programs
... care to fill in a clueless W2k user on how to stop W2k from moving past a BSOD too fast?
HOW do you change this? I think I have a corrupt video driver on my laptop which causes these crashes, but the damned thing keeps rebooting before I can get to the pause key
... the GUI does, but you don't *NEED* to do a reboot to change the IP info.
Use 'winipcfg' to force a refresh on the network card after you've changed your TCP/IP settings (make sure nothing that uses TCP/IP is running, though, this sometimes confuses it), and you can change your settings without needing a full reboot... I do it all the time.
20,000 free valid mailing addresses pointing to security-interested geeks sounds like a mailing list gold mine to me, and probably the marketing genius who thought up the poster idea. A $1000 investment into some nice shiny poster, a couple hundred bucks in postage, and you get a qualified database of hackers you can market to, and also sell to other companies if you feel like it ...
...
Bet we all get spammed with marketing material on security products in the future
But what about the flipside of this.
Would it be at all feasible, from a law perspective, to counter-sue Microsoft for *NEGLIGENCE* in protecting their so-called trade secrets?
Wouldn't it be possible to make the argument that since Microsoft *allowed* the source code to get out into the public domain, they are responsible for their own mess, and thus use that as a basis to dismiss any court cases that would be enacted based on this conspiracy theory.
It seems to me that this argument could be made fairly strongly - as is the case with trademarks - if you do not protect it, you do not deserve the right to exclusivity, and thus there would be no basis for damages should the code be 'used' elsewhere?
Can anyone with a strong legal background comment on the feasibility of this issue? It would seem to me that something like this could be argued in any case against Microsoft for this purpose.
Yup. Fuck it, 700mhz is 'lowend'? I have an AMD 700 mhz (non-Duron) that does just fine for my needs, and I never thought it'd be 'lowend' so soon... though maybe the Celeron/Duron aspect of the 'lowend' label makes sense...
Well, okay, I guess I should've explained that a bit further, but I didn't really want to go too off-topic ... in the case of one of my NT friends, a decision was made at his company recently to not do an upgrade from NT -> Win2000, but instead go from NT -> Linux for their servers... so, they're feeling a bit fragile right about now.
I don't see any Word screenshots ... not that I have any reason to doubt the WINE developers, but it sure would be nice to be able to show the NT bigots in my acquaintance, just to rub salt in their wounds a little ...
...
Not that I enjoy that sort of thing. Oh, what the heck, yes I do.
So, anyone got screenshots? Might be nice to get a big one with KDE or some other Linux-specific background props around it too
I didn't use dictionary.com, I used a real dictionary. Thanks for the reference though.
Your obsession with the size of my penis can mean only one thing: penis envy.
Maybe you'll get lucky, and be born male next lifetime...
Umm, you need to get a dictionary, you big feminist wanna be, you... you got your feminazi mindbot on automatic, and not actually *reading* the words you think you're reading...
Babe: n. baby.
Baby: defn. 2 (the one that fits), "the youngest of a family or group". defn. 3, "SLANG. plan, idea or project." --adj 1. "young"
So, the use of the word 'babe' in this case is highly appropriate, and actually very, very accurate.
There is no technology available now or forseeable in the future that will make it safe to fly a personal plane into a thunderstorm or into ice. There is no technology that will take away your ability to fly into them. The only technology that can do that is technology that keeps you on ground, always.
"If God had wanted man to fly, he would have given us wings."
"Flying is for the birds, not man."
etc.
What a dope you are. You can't see the sky for the clouds...
I have a few of those in my attic too.
...
I also have a Handspring Visor[Palm], which will evolve into a much more powerful computer, I'm sure of it, and it follows the same policy of using a permanent resident store for all data and applications...
Actually, I believe this is one of the reasons it's such a successful platform - the assumption that all data is always available, and there is no secondary 'commit' stage to offline storage means that the OS can be used a lot more efficiently by the end user
For that matter, with this sort of technology, using it for offline storage would be moot.
Hard drives are a hack because RAM is so expensive and difficult to maintain without loss (i.e. turn it off, away it goes). With this sort of technology, presumably we'd have a whole new realm of design to consider, such that we don't *need* offline storage (which is what hard drives used to be called) for the CPU to save to in case of power outage.
I look forward to the day when there's just memory, lots of it, it's very fast, and it doesn't require a lot of power to move parts around. *That* will be a computer worth obsessing about...
Fair enough, I do agree with you. Anti-NASA doesn't mean anti-SPACE.
But I often find the anti-NASA sentiment to be completely lacking any fundamental basis in reality, other than membership in the popular lynching culture that so many diletanttes seem to adhere to.
NASA has done a *hell* of a lot for space exploration... and if you take the time to actually peek behind the mud slung on NASA, you'll find an incredible amount of actual, real, hard-core scientific value.
Don't come to me with anti-NASA sentiments unless you've got a pile of NASA Tech Briefs sitting in your basement (like I do), and can refer to articles from 3 years back. Don't come to me with anti-NASA sentiments unless you know your way around the NASA web sites well enough to know how to get the full Apollo manuscripts and audio archives, unless you know the details of STS-33 and the significance it had on space exploration, unless you can tell me what the NBL is.
I don't want to hear your anti-NASA sentiments if you don't even know what NASA is, and what it's been all about all along...
It's an incredibly difficult thing to engineer rotating structures in space and *still* maintain the correct position in space in order to keep orbit.
There *are* rotating structures in the space station - they're called gyro's, and in fact they're used by the station to move around. There are gyro's all over the ISS - spin one up, and the station starts to move in that direction, slowly due to centrifugal force.
They're an efficient means of maintaining position, because they're run by electric (solar) power, and thus don't require expendable fuel like the retro rockets do...
On the last picture that shows the station with Z1 truss... keep in mind that the entire station is *13* stories tall from one end to the other right now.
That might give you a better idea of the scale of the thing.