A lot of this was probably due to beam splitters and whatnot. During the opening days of this, most theaters are projecting on two or three screens at once from a single copy of the film. I am fairly sure i saw a 3 way split last night, but for a 3 way split, it wasn't bad - probably because it's only been run through a projector once or twice.
I wouldn't be at all suprised if some theaters are bending the rules a bit and going well over the lucasfilm rules about multi-screen projections to 4 or more screens from a single print.
*sigh* You are talking about kernel preemption, or preempting the system task, not preemptive multitasking.
In many places in both the Linux (2.4/2.5) and Darwin kernel's (depending on the device drivers), both will fail to preempt themselves for a userland task. (Yes, Virginia, there are chunks of code even Darwin won't preempt) Likewise, in many places (even in extremely old versions of the linux kernel), preemption can happen. You would be correct to say that there is a focus in 2.5 for trying to eliminate or optimize a lot of the non-preemptable code and to say that Darwin experiences marginally lower average latency than Linux 2.4, but to use that as some way to measure system performance is as ridiculous as it is stupid.
Besides, if you want to get super technical, there are two robust and stable implementations of Posix realtime threads for linux (RTAI and RTLinux) that have existed for a number of years. Darwin has no such beast. Now we are talking latencies of 10-15 microseconds vs the low-millisecond ranges of either Darwin or Linux 2.4/2.5
And if you want to get even further into the technical mumbo-jumbo, the ARM processor can rock both the PPC and the X86 in terms of preemption. There are event's called FIQ's (Fast IRQ) on ARM that cause the processor itself to preempt ITSELF and execute some other code! You can call efficient FIQ code on the order of 10MHz and still run your normal stuff on top of the CPU -- and on Linux too -- on top of RTAI Posix RT threads -- or not!
Oh, and Intel makes the best ARM cores, too. Yeah and they have 32 bit registers just like your 64/128bit PPC's.
Where do you get 64 bits from? The registers in all the PPC chips that apple are currently using are 32 bits wide just like on x86.
Also your definitions of preemptive task switching and async i/o must be seriously wacked to say that linux can't do them and darwin can. As someone who has poked around in both systems kernels on both architectures, you are really missing the boat.
In fact, I'll go ahead and go so far as to say you are so fucking stupid, you should probably seriously consider rendering yourself incapable of propigation. Welcome to my killfile.
MOTHER OF GOD that is so SINISTER of them. Surely, the bit is there to serve SATAN!
I mean, how could it serve a legitimate purpose if you were using your webcam for, say, security purposes - to watch your empty office or house while you were away, or you just didn't want the LED to blink when it took a picture for say - your robot vision app? Won't someone PLEASE get these hardware engineers to stop including useful features in their devices?
The intel webcams have always had this nice little shutter on the front that you can close. A very nice feature.
Did you see that dual screen notebook the other day? The coolest thing about it wasn't the two screens, but the TRIPOD SCREW MOUNT underneath! A solution to the sweaty legs problem! It's like a desk you can carry in your laptop bag. Some of those tripods can get pretty small.
This is not a decent argument for opensourcing the software! If they want to havesomeone else maintain it at a later date, then they should specify in their contract that they will recieve the source code to the program developed.
In either case - company recieving source or not, the IP would belong to the company - not the contract programmer and they wouldn't have to say anything to him if they wanted to extend the application. Any company who would hire a programmer to develop an application from scratch that would not become the IP of the company (opensource or not) would be stupid.
I have to say one thing about your notion - If I were the company thinking about hiring you to write the software, you wouldn't be far enough along to be asking this question.
I'd have fired you long ago because you won't continue to support your work. (Of course, writing an app so good it never NEEDS suport is another matter altogether.) It's completely ridiculous to assume that publishing the source under whatever open license will instantly give you an army of developers willing to continue to support and continue developing on the application for free.
Normally what you'd do is write the opensource app, and then a compnay would hire you to extend and support your own application inside of their project - in that case, then you could start talking with the compnay about whether the changes would be opensourced or not. In this case, you're turning the whole thing on its head.
Still, you may be right in that opensourcing the project would be a good idea for the company - but that is a decision that should be made INDEPENDENT of the development itself. The company should approach the decision with the assumption that the package is already developed, or even better AFTER the package IS developed. Most importantly, do not give this company any kind of false hope about what opensourcing the software will do. If you are a developer who actually runs any opensource projects, I don't really know why you would even think of recommending this so soon.
The best feature of this puppy nobody is mentioning - screw-in tripod mount! Why in the hell someone didn't do this sooner is beyond me. You can carry a small tripod for your laptop and forego a work surface anywhere you either dont have one or need more room. A lot of these newer machines get so toasty you don't want to *actually* set them on your lap anyway -- sweat up your legs, and re-press your pants (if you are wearing the sort of pants that get pressed anyway)..
As far as I'm concerned, this design sucks with no integrated keyboard, and its requiring the user to hold the screens up to view them at any kind of angle is a total failure -- the thing is going to be HEAVY and HOT. Holding it in your hands for long enough to actually *READ* the eBook you've got on it is going to pain a lot of people.
Have them carry a little 14-15" LCD monitor with them. There are some that are very thin and have detachable stands. ViewSonic and Sony both have some new ones that are only about 1-2" thick and the casing is not much bigger than the screen on either side. In any case, it's probably just about as big as a laptop and could be carried in a similar bag for a presentation. Not bad compared to the cost of a projector that small.
The coolest system I've seen to track when people are in front of a TV uses both a motion sensor and an electic field sensor to find out if people are there - moving or no. It was part of some really expensive home automation project.
Use the application programs x2x and x2vnc to send mouse and keyboard data between computers over the network. It's kind of funky to see the mouse cursor move off the side of the macintosh onto the linux desktop, across that screen, and onto a 3rd monitor which is a windows pc. Keyboard focus follows the mouse cursor.
You'll probably like this setup better than a kvm anyway. I use it, but keep seperate keyboards/mice stowed behind the cases of any "slave" machines since sometimes i might need to assume direct control of them - games are not fond of taking control via VNC:-) You could use a KVM for this purpose too - to serve only as a backup to assume direct control of a PC when you can't get ahold of it with x2x or x2vnc.
On the issue of controlling a mixture of mac/pc's with a kvm (if you are dead set on it or if you wish to for the reasons i stated above), why not get one of those USB "port replicator" things with PS/2 keyboard and mouse ports on it? Certainly you could plug the outputs of a kvm into that, and it'd be a lot cheaper than some funky KVM that can handle a mixture of USB/PS2 keyboard or mouse control.
Adding electronics to drives to gain more space is not a particular good idea in this day and age. You are not going to get 1000 bytes out of a 100 byte read very often, probably only if you are reading text. As you note Video and Graphics are usually stored in formats that are already compressed, so storing them on a drive with hardware compression wont win you much. And as the article says, text doesn't take up any noticable amount of space anyway. So even if you mostly care about your source code etc, you probably doesn't have anywhere near a GB, which is 1% of a modern drive.
Actually, personally I have about 10GB of sourcecode on my computer. Yeah, i'm not most people, but I can point you out lots of servers with gigs upon gigs of spreadsheets, word documents, powerpoints, and loads of other highly compressable data. For a random sampling of data (ie not your mp3 collection) you can get 2:1 compression. Even stuff like your browser cache should compress to about 2:1 - maybe highter. The point is that it could buy a lot of people a lot of extra disk space in certain applications.
Furthermore, compression and decompression takes time, so it would lower the performance of the drive somewhat (no idea how much, but some).
Well not if you use hardware that can compress and decompress data at the maximum transfer rate of the controller. That's the point of doing it in hardware. A dedicated chip that can compress or decompress at 166MB/s is not far fetched at all. If you had such a chip, the only thing you'd experience is a performance GAIN since it would take the drive less time to read or write the smaller amount of compressed data from the physical disk - you wouldn't have to wait as long for reads or writes to complete. It might affect latency a small bit depending on your algorighm, but compression latency would easily be smaller than a drive's seek time and both actions could happen at the same time.
Wasn't Stacker those guys who made a piece of hardware to place between your drive and the IDE controller, to do the compression?
I don't know. Someone else who replied to me had heard of a hardware compression product. AFAIK, Stacker was only software.
I remember trying to cram as much as possible on my little 20mb hard drive -- I had DoubleSpace and then Stacker running to compress that thing to the utter maximum -- and I backed it up on floppies, too!
What my real question is, with as much abstraction going on between the ide controller and the drive platters as there is now, why haven't we seen more in the way of harddrive firmware except for better bad-sector remapping and the like? What about hardware compression? A little flash memory or a dedicated on-disk area and a compress/expand chip and we could probably fit quite a bit more on existing physical head/platter technology with not much speed loss -- In fact, we might see some speed GAIN if we only have to pull 100 bytes off of the disk to return 1000 bytes of data, etc.. Of course, it wouldn't give you any more space for your DivX;-) collections, but for those of us who actually store mostly normal files, a lot of source code, etc, it'd be great!
I guess, unfortunately, it requires a bit (ok a lot) of work getting an OS to play nice with such a gimmik, but would installing a "driver" for your hard drive compression electronics really be all that much different than for your video card or drive controller itself? -- then of course there is the question of a filesystem that can handle the indeterminate capacity of this kind of system. IE you couldn't necessarily delete a 100M file and fit another 100M file in the same physical storage space...
Who the hell doesnt like the 30 second skip? It's much faster than using the FF to skip commercial breaks by popping this button about 5 times then pressing the replay button once or twice to back up 8 seconds each to the start of the show.
I have found that most people who claim not to like the 30 second skip are simply stupid and don't ever think of using the 8 second backwards skip to compensate for the inevitable overshoot. 30 second skip then rewind is a pain in the ass, I agree.
This is the revival of a product released over 8 years ago, the Wyse Winterm 2930: a DOS/Pen based wireless Citrix winterm.
There was no RDP support of course because it hadn't even been envisioned by Microsoft at the time - in fact, Microsoft was having tremendous legal headaches involving software licensing on Citrix's special "multiple simeotaneous user" versions of Windows NT 3.1 and later 3.5. This culminated in the establishment of MS's internal "Hydra" project and the creation of Windows NT 4.0 Terminal Services Edition and the later integration of this "Terminal Services" software into as much as possible all the way down into the Windows XP Home edition.
Which is why this is now a viable product - Cheap touch panels, better batteries, and a larger market should make this product fly again - even if it is made by someone else.
A real wireless monitor -- now that would be something to see!
Short answer: Whichever each package maintainer prefers for each package. I.e. whichever produces the best and most stable code.
Long answer: Different architectures that Debian has ports or in-progress ports for may be unfit under the 2.95 compiler (SH4 comes to mind. Ugh. 2.95/sh4 sucks). Different architectures can specify default compilers or overrides for package compiles, as can the packages themselves. 'gcc' will normally run 2.95 out of a stock woody install unless you change your app-defaults to run the gcc-3.0
Quibble: Both compilers produce working and interoperable code. It's not like a lib compiled with gcc-3 will have problems being linked with a program compiled with gcc-2.95. It is logical and quite a good thing to have both choices. I think you'll find that other binary distributions are compiled with a myriad of gcc's.
You obviously haven't looked in the directory which contains the woody install disk images, because it's plain as day. The instructions for finding this and a description of what it's about are in the "Installing Debian/GNU Linux 3.0 (woody) for i386" guide that IS linked to from the woody webpages, which are linked from an obvious place on www.debian.org. Here is the direct URL since you're so dumb: http://www.debian.org/releases/woody/i386/install. en.txt
ISO images for woody aren't provided yet since the package list is currently changing; however, the instructions on the debian CD site and the scripts there will make you an ISO of this unrelased software easily. If that's not enough for you you can try some premade images from a source like http://www.linuxiso.org/debian.html Hell, there's even DVD images floating around. You can buy a preburned one here: http://www.linux-cd.com/store/cgi/store.cgi?client =14491123&action=serve&item=woody.html
Premade ISO's won't be available for woody until it is released. "Official" ISO's are available for previous relases from the official site at http://www.debian.org/CD/. Minimal images designed to replace a set of boot floppies, "netinst" cd's, are also linked to from that site at http://www.debian.org/CD/netinst/
I find it ironic that you seem to be capable of writing a novella about how inept you are at reading. You seem to know exactly what you want, but since www.debian.org doesn't show it to you in big bold letters on the front of the page, why you didn't click on the search button is entirely beyond my comprehension.
I will give to one of your points: that the default installer can be improved. For the woody release, it was decided "if it ain't broke don't fix it." The next release will contain a better one. If you really can't wait, make a woody netinst cd with the Progeny installer. Or can you not type "apt-get install pgi" successfully? Someone will probably make one of these available with the progeny installer after woody's release.
Think you can put together a better debian website? Why don't you sign up?
The proxy service runs *inside* of IIS, so it's possible to configure a virtual directory to proxy to a webserver on another machine. Hence, if this kind of configuration was upset in some fashon, you would get a virtual directory error from the IIS server running the proxy rather than an error message returned from the webserver which was holding the actual content.
Maybe they're packet filtering or proxying through a Windows machine "Routing and Remote Access" or Microsoft Proxy service, thus allowing the site to remain hosted on the FreeBSD. All the problems that are occuring could be the result of this
Although this is entirely fake...
on
Qt For The Console
·
· Score: 4, Informative
Although this is a big april fools hoax, a real example of a GUI that works on the console can be found over at PicoGUI. (as featured formerly on/. and elsewhere)
The display framework of PicoGUI is so extensible that it will work on everything from a text-only 2 line LCD display (or smaller) up to a fully realized 3d environment courtesy of OpenGL (needs someone to code it but the OpenGL "display" driver is already in there).
This is mostly possible because of PicoGUI's strict distinction between content and presentation (Remember the design goal of the original HTML? - Bingo.) Anyway, it's a neat project to check out; the support for this is in and working now; it runs on everything under the sun; and development continues to progress at an extremely rapid pace.
This is no different than what happens on VHF Ham's that use a Mic-E encoder for APRS position reporting. There is a 1/4-1/2 second 1200 baud data burst at the end of the transmission. It's really not annoying, and when you consider that either 1) the communication is important enough that you really shouldn't care about being interrupted for 1/4 second when someone else talking on a channel you are using is interrupting you for far longer, or 2) you wouln't even hear it anyway if you are using a coded squelch.
This whole product undoubtadely evolved from APRS. Anyone really interested in this unit would be blown away by APRS - It's the same idea but wider-range, internet-repeated, and has digital messaging capabilities.:)
They also cook faster and more evenly being flat. As far as a special enzyme goes, there's really no need to do that. Just take the liquefied chicken, press it together, batter, fry. It will hold its shape after that. They ship nuggets to area distributors liequefied in buckets since it's cheaper - they press and freeze the nuggets and send them the 'last mile' to McDonald's.
Slashdot Mirror
A lot of this was probably due to beam splitters and whatnot. During the opening days of this, most theaters are projecting on two or three screens at once from a single copy of the film. I am fairly sure i saw a 3 way split last night, but for a 3 way split, it wasn't bad - probably because it's only been run through a projector once or twice.
I wouldn't be at all suprised if some theaters are bending the rules a bit and going well over the lucasfilm rules about multi-screen projections to 4 or more screens from a single print.
*sigh* You are talking about kernel preemption, or preempting the system task, not preemptive multitasking.
In many places in both the Linux (2.4/2.5) and Darwin kernel's (depending on the device drivers), both will fail to preempt themselves for a userland task. (Yes, Virginia, there are chunks of code even Darwin won't preempt) Likewise, in many places (even in extremely old versions of the linux kernel), preemption can happen. You would be correct to say that there is a focus in 2.5 for trying to eliminate or optimize a lot of the non-preemptable code and to say that Darwin experiences marginally lower average latency than Linux 2.4, but to use that as some way to measure system performance is as ridiculous as it is stupid.
Besides, if you want to get super technical, there are two robust and stable implementations of Posix realtime threads for linux (RTAI and RTLinux) that have existed for a number of years. Darwin has no such beast. Now we are talking latencies of 10-15 microseconds vs the low-millisecond ranges of either Darwin or Linux 2.4/2.5
And if you want to get even further into the technical mumbo-jumbo, the ARM processor can rock both the PPC and the X86 in terms of preemption. There are event's called FIQ's (Fast IRQ) on ARM that cause the processor itself to preempt ITSELF and execute some other code! You can call efficient FIQ code on the order of 10MHz and still run your normal stuff on top of the CPU -- and on Linux too -- on top of RTAI Posix RT threads -- or not!
Oh, and Intel makes the best ARM cores, too. Yeah and they have 32 bit registers just like your 64/128bit PPC's.
Where do you get 64 bits from? The registers in all the PPC chips that apple are currently using are 32 bits wide just like on x86.
Also your definitions of preemptive task switching and async i/o must be seriously wacked to say that linux can't do them and darwin can. As someone who has poked around in both systems kernels on both architectures, you are really missing the boat.
In fact, I'll go ahead and go so far as to say you are so fucking stupid, you should probably seriously consider rendering yourself incapable of propigation. Welcome to my killfile.
~GoRK
MOTHER OF GOD that is so SINISTER of them. Surely, the bit is there to serve SATAN!
I mean, how could it serve a legitimate purpose if you were using your webcam for, say, security purposes - to watch your empty office or house while you were away, or you just didn't want the LED to blink when it took a picture for say - your robot vision app? Won't someone PLEASE get these hardware engineers to stop including useful features in their devices?
The intel webcams have always had this nice little shutter on the front that you can close. A very nice feature.
Did you see that dual screen notebook the other day? The coolest thing about it wasn't the two screens, but the TRIPOD SCREW MOUNT underneath! A solution to the sweaty legs problem! It's like a desk you can carry in your laptop bag. Some of those tripods can get pretty small.
This is not a decent argument for opensourcing the software! If they want to havesomeone else maintain it at a later date, then they should specify in their contract that they will recieve the source code to the program developed.
In either case - company recieving source or not, the IP would belong to the company - not the contract programmer and they wouldn't have to say anything to him if they wanted to extend the application. Any company who would hire a programmer to develop an application from scratch that would not become the IP of the company (opensource or not) would be stupid.
I have to say one thing about your notion - If I were the company thinking about hiring you to write the software, you wouldn't be far enough along to be asking this question.
I'd have fired you long ago because you won't continue to support your work. (Of course, writing an app so good it never NEEDS suport is another matter altogether.) It's completely ridiculous to assume that publishing the source under whatever open license will instantly give you an army of developers willing to continue to support and continue developing on the application for free.
Normally what you'd do is write the opensource app, and then a compnay would hire you to extend and support your own application inside of their project - in that case, then you could start talking with the compnay about whether the changes would be opensourced or not. In this case, you're turning the whole thing on its head.
Still, you may be right in that opensourcing the project would be a good idea for the company - but that is a decision that should be made INDEPENDENT of the development itself. The company should approach the decision with the assumption that the package is already developed, or even better AFTER the package IS developed. Most importantly, do not give this company any kind of false hope about what opensourcing the software will do. If you are a developer who actually runs any opensource projects, I don't really know why you would even think of recommending this so soon.
Hundreds of millions of people recognized the operating system known as DOS - DISK OPERATING SYSTEM, didn't they?
The best feature of this puppy nobody is mentioning - screw-in tripod mount! Why in the hell someone didn't do this sooner is beyond me. You can carry a small tripod for your laptop and forego a work surface anywhere you either dont have one or need more room. A lot of these newer machines get so toasty you don't want to *actually* set them on your lap anyway -- sweat up your legs, and re-press your pants (if you are wearing the sort of pants that get pressed anyway)..
As far as I'm concerned, this design sucks with no integrated keyboard, and its requiring the user to hold the screens up to view them at any kind of angle is a total failure -- the thing is going to be HEAVY and HOT. Holding it in your hands for long enough to actually *READ* the eBook you've got on it is going to pain a lot of people.
~GoRK
Have them carry a little 14-15" LCD monitor with them. There are some that are very thin and have detachable stands. ViewSonic and Sony both have some new ones that are only about 1-2" thick and the casing is not much bigger than the screen on either side. In any case, it's probably just about as big as a laptop and could be carried in a similar bag for a presentation. Not bad compared to the cost of a projector that small.
~GoRK
The coolest system I've seen to track when people are in front of a TV uses both a motion sensor and an electic field sensor to find out if people are there - moving or no. It was part of some really expensive home automation project.
Use the application programs x2x and x2vnc to send mouse and keyboard data between computers over the network. It's kind of funky to see the mouse cursor move off the side of the macintosh onto the linux desktop, across that screen, and onto a 3rd monitor which is a windows pc. Keyboard focus follows the mouse cursor.
:-)
You'll probably like this setup better than a kvm anyway. I use it, but keep seperate keyboards/mice stowed behind the cases of any "slave" machines since sometimes i might need to assume direct control of them - games are not fond of taking control via VNC
You could use a KVM for this purpose too - to serve only as a backup to assume direct control of a PC when you can't get ahold of it with x2x or x2vnc.
On the issue of controlling a mixture of mac/pc's with a kvm (if you are dead set on it or if you wish to for the reasons i stated above), why not get one of those USB "port replicator" things with PS/2 keyboard and mouse ports on it? Certainly you could plug the outputs of a kvm into that, and it'd be a lot cheaper than some funky KVM that can handle a mixture of USB/PS2 keyboard or mouse control.
~GoRK
Adding electronics to drives to gain more space is not a particular good idea in this day and age. You are not going to get 1000 bytes out of a 100 byte read very often, probably only if you are reading text. As you note Video and Graphics are usually stored in formats that are already compressed, so storing them on a drive with hardware compression wont win you much. And as the article says, text doesn't take up any noticable amount of space anyway. So even if you mostly care about your source code etc, you probably doesn't have anywhere near a GB, which is 1% of a modern drive.
Actually, personally I have about 10GB of sourcecode on my computer. Yeah, i'm not most people, but I can point you out lots of servers with gigs upon gigs of spreadsheets, word documents, powerpoints, and loads of other highly compressable data. For a random sampling of data (ie not your mp3 collection) you can get 2:1 compression. Even stuff like your browser cache should compress to about 2:1 - maybe highter. The point is that it could buy a lot of people a lot of extra disk space in certain applications.
Furthermore, compression and decompression takes time, so it would lower the performance of the drive somewhat (no idea how much, but some).
Well not if you use hardware that can compress and decompress data at the maximum transfer rate of the controller. That's the point of doing it in hardware. A dedicated chip that can compress or decompress at 166MB/s is not far fetched at all. If you had such a chip, the only thing you'd experience is a performance GAIN since it would take the drive less time to read or write the smaller amount of compressed data from the physical disk - you wouldn't have to wait as long for reads or writes to complete. It might affect latency a small bit depending on your algorighm, but compression latency would easily be smaller than a drive's seek time and both actions could happen at the same time.
Wasn't Stacker those guys who made a piece of hardware to place between your drive and the IDE controller, to do the compression?
I don't know. Someone else who replied to me had heard of a hardware compression product. AFAIK, Stacker was only software.
~GoRK
I remember trying to cram as much as possible on my little 20mb hard drive -- I had DoubleSpace and then Stacker running to compress that thing to the utter maximum -- and I backed it up on floppies, too!
;-) collections, but for those of us who actually store mostly normal files, a lot of source code, etc, it'd be great!
What my real question is, with as much abstraction going on between the ide controller and the drive platters as there is now, why haven't we seen more in the way of harddrive firmware except for better bad-sector remapping and the like? What about hardware compression? A little flash memory or a dedicated on-disk area and a compress/expand chip and we could probably fit quite a bit more on existing physical head/platter technology with not much speed loss -- In fact, we might see some speed GAIN if we only have to pull 100 bytes off of the disk to return 1000 bytes of data, etc.. Of course, it wouldn't give you any more space for your DivX
I guess, unfortunately, it requires a bit (ok a lot) of work getting an OS to play nice with such a gimmik, but would installing a "driver" for your hard drive compression electronics really be all that much different than for your video card or drive controller itself? -- then of course there is the question of a filesystem that can handle the indeterminate capacity of this kind of system. IE you couldn't necessarily delete a 100M file and fit another 100M file in the same physical storage space...
ideas. something to muse over
Who the hell doesnt like the 30 second skip? It's much faster than using the FF to skip commercial breaks by popping this button about 5 times then pressing the replay button once or twice to back up 8 seconds each to the start of the show.
I have found that most people who claim not to like the 30 second skip are simply stupid and don't ever think of using the 8 second backwards skip to compensate for the inevitable overshoot. 30 second skip then rewind is a pain in the ass, I agree.
~GoRK
Does anyone know the source of the minipci card or the antennas they are using? I'd sure love to cram one of these cards into my soekris net4501 box :)
This is the revival of a product released over 8 years ago, the Wyse Winterm 2930: a DOS/Pen based wireless Citrix winterm.
There was no RDP support of course because it hadn't even been envisioned by Microsoft at the time - in fact, Microsoft was having tremendous legal headaches involving software licensing on Citrix's special "multiple simeotaneous user" versions of Windows NT 3.1 and later 3.5. This culminated in the establishment of MS's internal "Hydra" project and the creation of Windows NT 4.0 Terminal Services Edition and the later integration of this "Terminal Services" software into as much as possible all the way down into the Windows XP Home edition.
Which is why this is now a viable product - Cheap touch panels, better batteries, and a larger market should make this product fly again - even if it is made by someone else.
A real wireless monitor -- now that would be something to see!
~GoRK
Short answer: Whichever each package maintainer prefers for each package. I.e. whichever produces the best and most stable code.
Long answer: Different architectures that Debian has ports or in-progress ports for may be unfit under the 2.95 compiler (SH4 comes to mind. Ugh. 2.95/sh4 sucks). Different architectures can specify default compilers or overrides for package compiles, as can the packages themselves. 'gcc' will normally run 2.95 out of a stock woody install unless you change your app-defaults to run the gcc-3.0
Quibble: Both compilers produce working and interoperable code. It's not like a lib compiled with gcc-3 will have problems being linked with a program compiled with gcc-2.95. It is logical and quite a good thing to have both choices. I think you'll find that other binary distributions are compiled with a myriad of gcc's.
It does quite clearly state this on the Netinst CD webpages and on the on-disc texts that the discs have multiple boot images.
BTW you could have asked nicely.
You obviously haven't looked in the directory which contains the woody install disk images, because it's plain as day. The instructions for finding this and a description of what it's about are in the "Installing Debian/GNU Linux 3.0 (woody) for i386" guide that IS linked to from the woody webpages, which are linked from an obvious place on www.debian.org. Here is the direct URL since you're so dumb: http://www.debian.org/releases/woody/i386/install. en.txt
i 386/current/bf2.4/
t =14491123&action=serve&item=woody.html
Here is the url to take you directly to the bootable 2.4 disk images.
http://http.us.debian.org/dists/woody/main/disks-
ISO images for woody aren't provided yet since the package list is currently changing; however, the instructions on the debian CD site and the scripts there will make you an ISO of this unrelased software easily. If that's not enough for you you can try some premade images from a source like http://www.linuxiso.org/debian.html Hell, there's even DVD images floating around. You can buy a preburned one here: http://www.linux-cd.com/store/cgi/store.cgi?clien
Premade ISO's won't be available for woody until it is released. "Official" ISO's are available for previous relases from the official site at http://www.debian.org/CD/. Minimal images designed to replace a set of boot floppies, "netinst" cd's, are also linked to from that site at http://www.debian.org/CD/netinst/
I find it ironic that you seem to be capable of writing a novella about how inept you are at reading. You seem to know exactly what you want, but since www.debian.org doesn't show it to you in big bold letters on the front of the page, why you didn't click on the search button is entirely beyond my comprehension.
I will give to one of your points: that the default installer can be improved. For the woody release, it was decided "if it ain't broke don't fix it." The next release will contain a better one. If you really can't wait, make a woody netinst cd with the Progeny installer. Or can you not type "apt-get install pgi" successfully? Someone will probably make one of these available with the progeny installer after woody's release.
Think you can put together a better debian website? Why don't you sign up?
The proxy service runs *inside* of IIS, so it's possible to configure a virtual directory to proxy to a webserver on another machine. Hence, if this kind of configuration was upset in some fashon, you would get a virtual directory error from the IIS server running the proxy rather than an error message returned from the webserver which was holding the actual content.
~GoRK
Maybe they're packet filtering or proxying through a Windows machine "Routing and Remote Access" or Microsoft Proxy service, thus allowing the site to remain hosted on the FreeBSD. All the problems that are occuring could be the result of this
Although this is a big april fools hoax, a real example of a GUI that works on the console can be found over at PicoGUI. (as featured formerly on /. and elsewhere)
The display framework of PicoGUI is so extensible that it will work on everything from a text-only 2 line LCD display (or smaller) up to a fully realized 3d environment courtesy of OpenGL (needs someone to code it but the OpenGL "display" driver is already in there).
Some examples:
X-Chat/PicoGUI running using PicoGUI's ncurses driver on the console:
http://www.picogui.org/sshotdetail.php?index=47
A couple of PicoGUI apps running on a 4 line Text LCD:
http://www.picogui.org/sshotdetail.php?index=64
PicoGUI running on OpenGL:
http://www.picogui.org/sshotdetail.php?index=60
This is mostly possible because of PicoGUI's strict distinction between content and presentation (Remember the design goal of the original HTML? - Bingo.) Anyway, it's a neat project to check out; the support for this is in and working now; it runs on everything under the sun; and development continues to progress at an extremely rapid pace.
~GoRK
This is no different than what happens on VHF Ham's that use a Mic-E encoder for APRS position reporting. There is a 1/4-1/2 second 1200 baud data burst at the end of the transmission. It's really not annoying, and when you consider that either 1) the communication is important enough that you really shouldn't care about being interrupted for 1/4 second when someone else talking on a channel you are using is interrupting you for far longer, or 2) you wouln't even hear it anyway if you are using a coded squelch.
:)
This whole product undoubtadely evolved from APRS. Anyone really interested in this unit would be blown away by APRS - It's the same idea but wider-range, internet-repeated, and has digital messaging capabilities.
~GoRK
They also cook faster and more evenly being flat. As far as a special enzyme goes, there's really no need to do that. Just take the liquefied chicken, press it together, batter, fry. It will hold its shape after that. They ship nuggets to area distributors liequefied in buckets since it's cheaper - they press and freeze the nuggets and send them the 'last mile' to McDonald's.