Damm, I really hoped SteveJobsLivesInMyClosetAndTellsMeThings.com was a real site.
OS X really had me hoping that the Holy Grail (Unix with a pretty face) had finally arrived. I'll admit it; the hardware is dead sexy, and if they had software to match, I'd order a G4 Cube tomorrow.
Yeah, I'm a long time Unix guy also. I got a G3 PowerBook and OSX PB. I'm pretty damm happy with it for a beta. It is missing DVD support, and iMovie seems not to work right. I can live with that (it makes a rocking wireless web and ssh and mail client -- the internal 802.11 and antenna rocks). As a Unix head the missing features are only an irratation. A pretty big one. But I still like the G3 beter then the Viao 505JS I had before.
Did anybody really expect that, beginning March 24, 2001, every Mac user would be using Mac OS X?
Of corse not. Not without most of their applications running naitave (outside of the Clasic box). I did expect everything the devlopers needed to do ports to be there. That the apps could be rolled out on that release (or minor patches thereof), and users could move when their apps got moved.
I didn't expect Apple to still be dicking with the UI in January. I didn't expect major peripherals to be unsupported. In short I didn't expect Apple to blow the release date a 5th (or so) time. I guess I'm pretty dumb.
SMP is not as important as you think, because there aren't very many multi-processor systems available right now. In fact, it's almost impossible to get one. By the summer, the machines will be more commonly available, and THEN it gets important as to what the OS does with it. At the moment with 9.1, SMP just isn't going to work. With OS X, it'll work, just not as well as they know they can make it.
Lots of high end PhotoShop users have multiprocessor systems. I think most are 3rd party (sort of supported by Apple through a really unfriendly API -- one of the few not available in Carbon).
It is also really really odd that a MACH kernel won't multitask, that was one of the key research areas for MACH. I wonder if they mean there is no fine-grained SMP (i.e. not much better then a "one big lock kernel") -- if so it is way better then OS9's multi-CPU support (one CPU is limited to a tiny handful of kernel calls *ever*, and that is user visable, threads are bound to CPUs, and any CPU other then the primary one can baiscally only send messages to threads on the other CPUs to ask them to do OS calls).
A. Dual-booting has always been an expected obligation until new versions of all the traditional Mac software are ported specifically OS X. Nobody but hack journalists are surprised. Most savvy Mac users consider this a real boon, as a kind of long-term protection measure for expensive software and years of skill investment. It eases the transition into the new Unix world.
No. Some applications starting up clasic under OSX for you, and running there is expected. Having to reboot into OS9 is not expected, and IMHO not acceptable. MacDraw 0.8 for the 68000 runs in the compatability box for crying out loud, why can't the DVD player at least do as well as software Apple wrote over 15 years ago for a diffrent CPU!
B. As of the latest build, sleep functions on PowerBooks work perfectly, with two-second wake-up times. That's right: two seconds.
Seems to be faster then that. Normally faster then I can open the lid enough to see the screen. They might be playing a trick and repainting a saved screen beofre getting the apps live though.
C. DVD playing is hardly a "key feature." DVD burning was *never* a key feature, nor was CD-RW. Until only recently this was always a third-party software opportunity.
It is when Apple targets the video market (makers of comercials, and movies). Plus I payed Apple to get a DVD player on a portable, I expect them to make it work. Even if it has to run in the compatibility box.
A 10Ghz transister can only make a 10Ghz CPU if each pipeline stage (plus sync overhead) is only a single transister. Which is pretty impossable (a simple flip flop is several transistors, an adder is a big pile of them). As I recall the failed 500Mhz PowerPC that some compony like "eXponential" was making was thought to be extreamly aggressave with only 50 or so transitor delays between pipe stages (and some pipe stages were mostly wire delay to get the signals from one part of the chip to another!). Or maybe I'm confusing that with sombody or others barrel processer style MediaCPU (also out of bisness).
Tiny transistors are wonderflu. Tiny fast transistors are more wonderful. But 10Ghz transistors are no where close to letting you make a 10Ghz CPU. In fact it might be slower then current state of the art (but smaller). Something in this story doesn't add up.
"You can do more damage by looking directly at the sun than by looking at one of these things,"
On the other hand people know not to look at the sun, (a) they have been tought not too as a child, (b) it hurts when they do it. These things apparently arn't visable, so you might do it without knowing it, if the emitter is sufficently intresting looking...
(no, I don't think it is a huge threat, but I just had to point it out)
Deliberately spreading rumors
or insulting another person is against the law
From my dimly remembered high school law classes there are some signifigant exceptions to libel and slander in the USA.
A true statment (or one that would have been beleved to be true to a reasonable person) is not libel (or slander). In the UK I have been told that trueth is not an absolute shield, and you can be found guilty if you speed the truth with an intent to harm. In the USA trueth is an absolute shield. Absolute. To a lesser extent the "look I had this evidence, and it seemed valid and compelling, even though it later turned out wrong" is a shield, but apparently not absolute.
There are also exceptions to things that are clear parodies. This is how Hussler got away with saying all manner of nasty things about Jerry Fallwell. I think that case went to the US Suprime Court.
There are also exceptions for public figures, but they are more narrow, and I think it really just brodens the other exceptions (like you might get in trubble for writing that I'm a wife beater, baised on flimsy evidence, but maybe not for a TV star baised on the same evidence).
Remember, I'm not a laywer, and worse then that this is baised on information more then ten years old (the law does change), and even worse was gained in a USA public school. The same one that didn't teach me to spell. So there may be more exceptions, or fewer. Or something. Talk to a real lawyer before you try to "not quite" slander (or libel) someone.
Their lunch is being eaten from above by Windows and Linux, and from below by uCLinux, eCos, and other free RTOSes.
Is eCos really popular? I havn't seen much mention of it in embeded systems journels, or any body claiming to use it in shipping products. I think eCos is kind of cool, and would be delighted to hear that it is popular...
That leaves only the lack of legal precedents pertaining to the GPL. Yet the overwhelming majority of commercial software licenses, including Wind River's, are not court-tested and many of their provisions are blatantly unenforceable in many jurisdictions. This argument does not hold water.
That is exactly what I've been thinking. Version 1 of the GPL is a lot older then most comercial software licences, and so far all chalangers to the GPL have decided to settle out of court (by releasing the code). I think that speaks almost as strongly as a court victory.
Royalty-free OS coupled with potentially royalty-free hardware has an obvious appeal to many industries.
I don't think the car industry is going to be all that excited about getting a 16Mhz pair of CPUs on a chip that costs a lot more then a "real" 200Mhz ARM. One that can actually multiply numbers in hardware, and you know, has been tested.
A lot can come up going froma simulated FPGA design to the real hardware. Sometimes it can be fixed just by bringing the clock speed down a bit, but other times if you had an overdriven line or something the simulator will be great and real hardware a nightmare. Of corse I have done very very little FPGA work (population count, a NFA evaluator, a few other toy projects).
None of this means the BlackARM is crap, if someone works on it for a long time it could be useful, maybe optmised for an ASIC so it is cheeper (in quantity), and faster. Or maybe just using it (as is) to exparament with CPU perphrial integration (15Mhz CPU with an AES engine). It definitly had value in providing a duel CPU on a chip test platform for a lucky (hard working) Phd candiate...
P.S. I'm assuming the pair of ARMs is on a Xylinx Virtex baised on the 16K RAM number. The Spartin line doesn't have nearly that much RAM, but that is a lot more affordable, starting at under $1. The Virtex is still quite costly, it has a lot more gates, the SRAM, and and a higher max clock if you keep the circuit chains short (i.e. pipeline).
As far as I know the IETF doesn't like people publishing RFCs for technology that is patented, but they don't seem to have a similar policy for RFCs for protocalls that have a trademark infringing name, and no useful open use of the mark. Or do they and it was violated with SSH?
SMTP is the protocall, sendmail is the program and trademark. DNS is the protocall, bind is the program, and if there is a service mark it is bind, not DNS.
Why should SSH1/SSH2 be accepted as an open standard if nothing can be named that (or the very similar OpenSSH)?
I do think there are acceptable uses of a trademark on protocall names. If the trademark were used to make sure nothing was called "RADIUS" unless it implmented all the MUST parts of the RFC, none of the MUST NOT, and provided a argment on why SHOULD/SHOULD NOT wasn't followed, then I'm all for it. In that case the mark is actually protecting the word. For SSH the mark is being used after the fact to un-level the playing field.
Not only do you need the source, but you also need a compiler for the particular DSP used by the modem.
Yeah, ok for anything other then "understanding" the code you also need to compile it. Of corse a big old datasheet for the DSP would let someone hack up a version of gcc, or a perl script that may be able to compile things. It is much harder to turn a big binary glob into useful source.
Driver source with binary firmware glob -- nice start. Driver source with firmware source (and bin) even better, but not perfect. Driver source with firmware source, and firmware compiler source way better (let's assume the firmware compile is written in a language we already have a compiler/interpreter for).
No offense, but unless I missed an important lecture in thermodynamics, how can they hope to make money from this? It takes more power (which equals money in the eyes of the power companies) to pump water uphill then they can get from it going downhill...
You didn't miss a thermo lecture, just a economics one. A given commody market value can vary over time. Storing it and paying rent on the storage and selling it later can be quite profitable. It can also lead to quite a loss if the price never goes up enough (or you can't wait that long).
That's what makes the stock market work. And the power market. And the futures market. And...
Trading a thick heavy but otherwise low-maintenance copper cable for a thin light but very high-maintenance superconducting one?
According to the article the existing copper cables are cooled with oil. I expect that means they are only replacing existing high mantinance (high capicity?) cables with these things.
I don't know enough about power distribution systems to know where these cables live, but I'm betting they are not the overhead phone pole kind. Maybe they are only found much closer to the genneration systems.
Those 'dsp' files are firmware to be loaded into the modem card itself, and processed onboard. There is no reason we need source for these, and the same files would be used no matter what OS it is.
Sure there is. If you want to fix or improve the DSP part, or even understand it (or build sonar with it). Which are very big parts of what opensource is about, not just "it can run everywhere", but "it runs good".
I expect with the DSP part you could make a "voice modem" and build your own voice mail system.
IBM did a good thing making the kernel part opensource, but the DSP part is still closed source, and to get full advantage of this hardware you need that part too.
However I believe that Ricochet had faster speeds available, whereas CDPD is 33Kbit.
33Kbit/sec? That might be in thery, but I havn't ever seen better then about 9Kbit/sec off of the AeroCard I have. And it displays the stats whenever it is running. It is worthless for looking at the web. It is fine for using ssh to read mail, and the one time I had to code I was sooooo glad I use all the little "3 words forward" type commands in vi because the latency was really bad (three or four seconds).
Unfortunately it doesn't compile immediately here on RedHat 6.0, (conflicting definitions of wchar_t in glibc and XFree86, of all things), so I can't post screenshots. If someone *does* manage to get it to compile and work (any experts on porting from X10 here?) why not post a reply and keep us all informed?:)
You can simulate it for purposes of a screen shot pretty easally. Arange your windows in a normal window manager. Kill the window manager. Take a screen shot.
UWM has (or had) no title bars, no window borders, no icon box, no icons, no menu bar, no on screen hint of any kind that it was running. Well, except when you were actually draggin or resizing a window, it gave the rubberband, and maybe a little text (I havn't used it for about a decade!). I think it had manus when you clicked the root window, but they were in the fixed font, and plain black on white with the circle cursor.
TWM really was the Enlightment of it's day. I fiddled with config files for hours and hours. In fact I hacked it to use M4 to preprocess the config files so I could waste even more time tweeking config files (as far as I can tell the FVWM M4 code was at least inspired by mine as it sets all the same macro values).
.Net encompasses a great deal of change for the Windows platform. But in this case, the piece of.Net being discussed between Microsoft and Sun is SOAP, or essentially XML based RPC over HTTP.
That may be, but I am discussing.Net itself, not just part of it. As far as I can tell to make a useful GUI.Net program you need to use a lot of Windows APIs. I wrote a ssh client in Java, and looked into making a C# one. I learned enough about C# to like it, and enough about.Net to not write it. If I have enough free time I may still do the C# version. I expect to use it less then the Java one (I normally only use it to get mostly secure access from odd places)
It's amazing to me the number of people who complain about.Net and just don't get it, primarily because they aren't willing to sit down and learn about it.:(
It is unsupprising, the damm thing is big, and as you said before Microsoft communicates about it poorly. Most people have limited time. I know I do. I spent the weekend looking for framing shots for my film class, I have more hobbies then just computers. I do still feel I know enough about.Net to talk about it. I also realise I don't know enough to really be right about all of it. You seem to imply that you know more about it then me. Is it possable to write a GUI C# program that is portable to systmes that don't implment most of the Windows API? Or are the Unix.Net implmentations going to be as limited as, say, the SmartCard Java implmentations?
Not true. The.NET runtime can be installed on any platform it is implemented for, just like a JVM. Right now, there's only one runtime, and that one for Win32 and it's only in beta yet. For Java, the situation is, of course, much different.
There is a reason, other then a multi-year-headstart, that Java's runtime is available for a lot of platforms. The amount of Java's runtime that is not (or can't be) written in Java is quite small. Limited mostly to drawing primataves, low level I/O, and a few other things..NET seems to drag along a signifigant part of the Windows API. That's great on Windows, but when you are on signifigantly diffrent systems you are screwed unless Microsoft implments them for dozens of platforms, or manages the substantal task of re-writing them in C# or another.NET language.
For GUI apps, it's my understanding that.NET doesn't even support them directly through the framework API. Instead, something called the Windows Forms API is used.
Oops, it seems we are arguing along similar lines.
I do assert that even if the Win API is not offically part of.NET, if there is no supplyed substitute (on Windows!), and no effort by MS to get it used, and easy access to the "non-standard WinAPI" then it will become a de facto.NET standard, and it will be tied to Windows.
Not that it is wholy bad to give Windows a decent language (C# is decent), but it isn't the step into the open platform world that MS asserts it is.
BTW, 'deprecated' is not the same as invalidated. You can still use them, it's just that you get a warning at compile time saying there's a better way, have a look at the docs...Which strikes me as a fairly civilised way of doing things.
Deprecated items can also be removed one full release after they have been marked deprecated (i.e. Java 3 does not have to include things listed as deprecated in Java 2, but they do have to exist in Java 2.7).
They don't have to be removed, but I expect if something has been deprecated for multple full releases and finally goes away it'll be a Real Bad Thing.
Still I would rather have deprecated API calls plus a set of nice sensable calls then a mish-mash of dozens of ways to do it with no clear indication of which is really the best. It is nice to see Sun saying "Oh, awt was a mistake, here is a easier thing to use, and if it isn't good enough we'll fix that too". The alternitave is something like X, or Windows. Or libc.
At the moment the only time I can forsee taking the time out to learn.NET APIs and (possibly) C#, is if I can't get an interesting job writing Java.
C# has some nice features (which like Java all appeared elsewhere first). If I didn't have to learn the MS APIs to use it well I would be intrested. Oh, and if it ran on, say, half the platforms Java does. Regretably I think the boxing and unboxing and better destruction sementics will make it hard to implment as a language on top of the JVM...
As for those embedded systems, it wouldn't surprise me if they were running a scaled down version of X.
There actually is a version of GTK and GDK that run on top of a raw framebuffer (just like there is a Qt that does the same). It in and of itself has to reimplment most of the X drawing primitaves (because GDK allows only lightly abstracted access to most of them), and a small window manager like bit. It is probbably still smaller then the small X server. But less useful.
Yes, I said small X server without gaging. I thought Keith Packard had done one weighing in at about 600K, which isn't tiny, but unless you are a Palm Pilot it isn't worth writing a new windowing system just to get smaller. (all of the little Linux capable PDAs sport a fair chunk of memory, enough that I would say take X, spend the time getting a hotsync, or support for a USB FM Tuner, or something cool)
Great, but what about updating all the ports software you installed?
I don't know of a way, there might be one. I havn't done many source upgrades, so it hasn't been an issue until lately. I havn't checked the handbook.
What about preserving configuration files?
That is that the mergemaster step does. Deals with conf files you havn't touched, and gives you diff's for the rest.
What if you don't want to "make world" a whole distribution? Compile? Thats a joke.
I like to compile my world. I like to know for a fact that if I patch someting and recompile the only change is the patch.
What is the point of having a distribution if you have to compile all your updates/additions?
It is faster for me to do that then download a new install image, and I have a 256K Frame-Relay, and a relitavly slow CPU. It seems like a better tradeoff to deal in compressed source then whole binary images.
It would seem that the FreeBSD way is more that a little more complicated. Many of the features just are not there. But thats Ok. Its probably one of those things where you don't need it until you have it. I mean, I was perfectly happy with COMMAND.COM, freeing up conventional memory, allocating XMS memory, and programming using SEG:OFFSET addressing under DOS before I first installed Linux. Sure, DOS can use all 64MB of RAM in your computer, its just a little more complicated:)
Well, feel free to tell me how the other ones does it better. I wasn't saying FreeBSD is the ultimate, just that it ain't bad. I know for a fact it's VM system isn't as good as NetBSD's (NetBSD's UVM rocks, even if it needs to be tuned), it isn't as secure as OpenBSD, and you can't buy support for it as easily as BSD/OS. I've even heard Linux has a thing or two it's good at too:-)
I would love to go on, but if you have never really spent time using/upgrading/maintaining Debian systems, you just have no idea. There is no point in trying explain it.
That's a copout. I've been thinking of trying a Linux. Convince me Debian is the one.
Some kind of a meta port that installs a userfriendly desktop along with a standard set of apps would be super cool.
Have you looked at the/usr/ports/x11/gnome "meta-port" for the GNOME integrated X11 desktop? Seems like what you want. I assume there is a KDE one as well.
Slashdot Mirror
Damm, I really hoped SteveJobsLivesInMyClosetAndTellsMeThings.com was a real site.
Yeah, I'm a long time Unix guy also. I got a G3 PowerBook and OSX PB. I'm pretty damm happy with it for a beta. It is missing DVD support, and iMovie seems not to work right. I can live with that (it makes a rocking wireless web and ssh and mail client -- the internal 802.11 and antenna rocks). As a Unix head the missing features are only an irratation. A pretty big one. But I still like the G3 beter then the Viao 505JS I had before.
Of corse not. Not without most of their applications running naitave (outside of the Clasic box). I did expect everything the devlopers needed to do ports to be there. That the apps could be rolled out on that release (or minor patches thereof), and users could move when their apps got moved.
I didn't expect Apple to still be dicking with the UI in January. I didn't expect major peripherals to be unsupported. In short I didn't expect Apple to blow the release date a 5th (or so) time. I guess I'm pretty dumb.
Eh? I've been using all the printers at work just great. Granted they are all PostScript LPRNG printers, but it was super-trivial to set them up.
Lots of high end PhotoShop users have multiprocessor systems. I think most are 3rd party (sort of supported by Apple through a really unfriendly API -- one of the few not available in Carbon).
It is also really really odd that a MACH kernel won't multitask, that was one of the key research areas for MACH. I wonder if they mean there is no fine-grained SMP (i.e. not much better then a "one big lock kernel") -- if so it is way better then OS9's multi-CPU support (one CPU is limited to a tiny handful of kernel calls *ever*, and that is user visable, threads are bound to CPUs, and any CPU other then the primary one can baiscally only send messages to threads on the other CPUs to ask them to do OS calls).
No. Some applications starting up clasic under OSX for you, and running there is expected. Having to reboot into OS9 is not expected, and IMHO not acceptable. MacDraw 0.8 for the 68000 runs in the compatability box for crying out loud, why can't the DVD player at least do as well as software Apple wrote over 15 years ago for a diffrent CPU!
Seems to be faster then that. Normally faster then I can open the lid enough to see the screen. They might be playing a trick and repainting a saved screen beofre getting the apps live though.
It is when Apple targets the video market (makers of comercials, and movies). Plus I payed Apple to get a DVD player on a portable, I expect them to make it work. Even if it has to run in the compatibility box.
I'll give you D and E though.
A 10Ghz transister can only make a 10Ghz CPU if each pipeline stage (plus sync overhead) is only a single transister. Which is pretty impossable (a simple flip flop is several transistors, an adder is a big pile of them). As I recall the failed 500Mhz PowerPC that some compony like "eXponential" was making was thought to be extreamly aggressave with only 50 or so transitor delays between pipe stages (and some pipe stages were mostly wire delay to get the signals from one part of the chip to another!). Or maybe I'm confusing that with sombody or others barrel processer style MediaCPU (also out of bisness).
Tiny transistors are wonderflu. Tiny fast transistors are more wonderful. But 10Ghz transistors are no where close to letting you make a 10Ghz CPU. In fact it might be slower then current state of the art (but smaller). Something in this story doesn't add up.
On the other hand people know not to look at the sun, (a) they have been tought not too as a child, (b) it hurts when they do it. These things apparently arn't visable, so you might do it without knowing it, if the emitter is sufficently intresting looking...
(no, I don't think it is a huge threat, but I just had to point it out)
From my dimly remembered high school law classes there are some signifigant exceptions to libel and slander in the USA.
A true statment (or one that would have been beleved to be true to a reasonable person) is not libel (or slander). In the UK I have been told that trueth is not an absolute shield, and you can be found guilty if you speed the truth with an intent to harm. In the USA trueth is an absolute shield. Absolute. To a lesser extent the "look I had this evidence, and it seemed valid and compelling, even though it later turned out wrong" is a shield, but apparently not absolute.
There are also exceptions to things that are clear parodies. This is how Hussler got away with saying all manner of nasty things about Jerry Fallwell. I think that case went to the US Suprime Court.
There are also exceptions for public figures, but they are more narrow, and I think it really just brodens the other exceptions (like you might get in trubble for writing that I'm a wife beater, baised on flimsy evidence, but maybe not for a TV star baised on the same evidence).
Remember, I'm not a laywer, and worse then that this is baised on information more then ten years old (the law does change), and even worse was gained in a USA public school. The same one that didn't teach me to spell. So there may be more exceptions, or fewer. Or something. Talk to a real lawyer before you try to "not quite" slander (or libel) someone.
Is eCos really popular? I havn't seen much mention of it in embeded systems journels, or any body claiming to use it in shipping products. I think eCos is kind of cool, and would be delighted to hear that it is popular...
That is exactly what I've been thinking. Version 1 of the GPL is a lot older then most comercial software licences, and so far all chalangers to the GPL have decided to settle out of court (by releasing the code). I think that speaks almost as strongly as a court victory.
I don't think the car industry is going to be all that excited about getting a 16Mhz pair of CPUs on a chip that costs a lot more then a "real" 200Mhz ARM. One that can actually multiply numbers in hardware, and you know, has been tested.
A lot can come up going froma simulated FPGA design to the real hardware. Sometimes it can be fixed just by bringing the clock speed down a bit, but other times if you had an overdriven line or something the simulator will be great and real hardware a nightmare. Of corse I have done very very little FPGA work (population count, a NFA evaluator, a few other toy projects).
None of this means the BlackARM is crap, if someone works on it for a long time it could be useful, maybe optmised for an ASIC so it is cheeper (in quantity), and faster. Or maybe just using it (as is) to exparament with CPU perphrial integration (15Mhz CPU with an AES engine). It definitly had value in providing a duel CPU on a chip test platform for a lucky (hard working) Phd candiate...
P.S. I'm assuming the pair of ARMs is on a Xylinx Virtex baised on the 16K RAM number. The Spartin line doesn't have nearly that much RAM, but that is a lot more affordable, starting at under $1. The Virtex is still quite costly, it has a lot more gates, the SRAM, and and a higher max clock if you keep the circuit chains short (i.e. pipeline).
As far as I know the IETF doesn't like people publishing RFCs for technology that is patented, but they don't seem to have a similar policy for RFCs for protocalls that have a trademark infringing name, and no useful open use of the mark. Or do they and it was violated with SSH?
SMTP is the protocall, sendmail is the program and trademark. DNS is the protocall, bind is the program, and if there is a service mark it is bind, not DNS.
Why should SSH1/SSH2 be accepted as an open standard if nothing can be named that (or the very similar OpenSSH)?
I do think there are acceptable uses of a trademark on protocall names. If the trademark were used to make sure nothing was called "RADIUS" unless it implmented all the MUST parts of the RFC, none of the MUST NOT, and provided a argment on why SHOULD/SHOULD NOT wasn't followed, then I'm all for it. In that case the mark is actually protecting the word. For SSH the mark is being used after the fact to un-level the playing field.
Yeah, ok for anything other then "understanding" the code you also need to compile it. Of corse a big old datasheet for the DSP would let someone hack up a version of gcc, or a perl script that may be able to compile things. It is much harder to turn a big binary glob into useful source.
Driver source with binary firmware glob -- nice start. Driver source with firmware source (and bin) even better, but not perfect. Driver source with firmware source, and firmware compiler source way better (let's assume the firmware compile is written in a language we already have a compiler/interpreter for).
You didn't miss a thermo lecture, just a economics one. A given commody market value can vary over time. Storing it and paying rent on the storage and selling it later can be quite profitable. It can also lead to quite a loss if the price never goes up enough (or you can't wait that long).
That's what makes the stock market work. And the power market. And the futures market. And...
According to the article the existing copper cables are cooled with oil. I expect that means they are only replacing existing high mantinance (high capicity?) cables with these things.
I don't know enough about power distribution systems to know where these cables live, but I'm betting they are not the overhead phone pole kind. Maybe they are only found much closer to the genneration systems.
Sure there is. If you want to fix or improve the DSP part, or even understand it (or build sonar with it). Which are very big parts of what opensource is about, not just "it can run everywhere", but "it runs good".
I expect with the DSP part you could make a "voice modem" and build your own voice mail system.
IBM did a good thing making the kernel part opensource, but the DSP part is still closed source, and to get full advantage of this hardware you need that part too.
33Kbit/sec? That might be in thery, but I havn't ever seen better then about 9Kbit/sec off of the AeroCard I have. And it displays the stats whenever it is running. It is worthless for looking at the web. It is fine for using ssh to read mail, and the one time I had to code I was sooooo glad I use all the little "3 words forward" type commands in vi because the latency was really bad (three or four seconds).
You can simulate it for purposes of a screen shot pretty easally. Arange your windows in a normal window manager. Kill the window manager. Take a screen shot.
UWM has (or had) no title bars, no window borders, no icon box, no icons, no menu bar, no on screen hint of any kind that it was running. Well, except when you were actually draggin or resizing a window, it gave the rubberband, and maybe a little text (I havn't used it for about a decade!). I think it had manus when you clicked the root window, but they were in the fixed font, and plain black on white with the circle cursor.
TWM really was the Enlightment of it's day. I fiddled with config files for hours and hours. In fact I hacked it to use M4 to preprocess the config files so I could waste even more time tweeking config files (as far as I can tell the FVWM M4 code was at least inspired by mine as it sets all the same macro values).
Oh, I don't doubt that many of them are. But how much of what you need for a GUI are?
That may be, but I am discussing .Net itself, not just part of it. As far as I can tell to make a useful GUI .Net program you need to use a lot of Windows APIs. I wrote a ssh client in Java, and looked into making a C# one. I learned enough about C# to like it, and enough about .Net to not write it. If I have enough free time I may still do the C# version. I expect to use it less then the Java one (I normally only use it to get mostly secure access from odd places)
It is unsupprising, the damm thing is big, and as you said before Microsoft communicates about it poorly. Most people have limited time. I know I do. I spent the weekend looking for framing shots for my film class, I have more hobbies then just computers. I do still feel I know enough about .Net to talk about it. I also realise I don't know enough to really be right about all of it. You seem to imply that you know more about it then me. Is it possable to write a GUI C# program that is portable to systmes that don't implment most of the Windows API? Or are the Unix .Net implmentations going to be as limited as, say, the SmartCard Java implmentations?
There is a reason, other then a multi-year-headstart, that Java's runtime is available for a lot of platforms. The amount of Java's runtime that is not (or can't be) written in Java is quite small. Limited mostly to drawing primataves, low level I/O, and a few other things. .NET seems to drag along a signifigant part of the Windows API. That's great on Windows, but when you are on signifigantly diffrent systems you are screwed unless Microsoft implments them for dozens of platforms, or manages the substantal task of re-writing them in C# or another .NET language.
Oops, it seems we are arguing along similar lines.
I do assert that even if the Win API is not offically part of .NET, if there is no supplyed substitute (on Windows!), and no effort by MS to get it used, and easy access to the "non-standard WinAPI" then it will become a de facto .NET standard, and it will be tied to Windows.
Not that it is wholy bad to give Windows a decent language (C# is decent), but it isn't the step into the open platform world that MS asserts it is.
Deprecated items can also be removed one full release after they have been marked deprecated (i.e. Java 3 does not have to include things listed as deprecated in Java 2, but they do have to exist in Java 2.7).
They don't have to be removed, but I expect if something has been deprecated for multple full releases and finally goes away it'll be a Real Bad Thing.
Still I would rather have deprecated API calls plus a set of nice sensable calls then a mish-mash of dozens of ways to do it with no clear indication of which is really the best. It is nice to see Sun saying "Oh, awt was a mistake, here is a easier thing to use, and if it isn't good enough we'll fix that too". The alternitave is something like X, or Windows. Or libc.
C# has some nice features (which like Java all appeared elsewhere first). If I didn't have to learn the MS APIs to use it well I would be intrested. Oh, and if it ran on, say, half the platforms Java does. Regretably I think the boxing and unboxing and better destruction sementics will make it hard to implment as a language on top of the JVM...
There actually is a version of GTK and GDK that run on top of a raw framebuffer (just like there is a Qt that does the same). It in and of itself has to reimplment most of the X drawing primitaves (because GDK allows only lightly abstracted access to most of them), and a small window manager like bit. It is probbably still smaller then the small X server. But less useful.
Yes, I said small X server without gaging. I thought Keith Packard had done one weighing in at about 600K, which isn't tiny, but unless you are a Palm Pilot it isn't worth writing a new windowing system just to get smaller. (all of the little Linux capable PDAs sport a fair chunk of memory, enough that I would say take X, spend the time getting a hotsync, or support for a USB FM Tuner, or something cool)
I don't know of a way, there might be one. I havn't done many source upgrades, so it hasn't been an issue until lately. I havn't checked the handbook.
That is that the mergemaster step does. Deals with conf files you havn't touched, and gives you diff's for the rest.
I like to compile my world. I like to know for a fact that if I patch someting and recompile the only change is the patch.
It is faster for me to do that then download a new install image, and I have a 256K Frame-Relay, and a relitavly slow CPU. It seems like a better tradeoff to deal in compressed source then whole binary images.
Well, feel free to tell me how the other ones does it better. I wasn't saying FreeBSD is the ultimate, just that it ain't bad. I know for a fact it's VM system isn't as good as NetBSD's (NetBSD's UVM rocks, even if it needs to be tuned), it isn't as secure as OpenBSD, and you can't buy support for it as easily as BSD/OS. I've even heard Linux has a thing or two it's good at too :-)
That's a copout. I've been thinking of trying a Linux. Convince me Debian is the one.
Have you looked at the /usr/ports/x11/gnome "meta-port" for the GNOME integrated X11 desktop? Seems like what you want. I assume there is a KDE one as well.