There are big problems with all of these techniques.
Worm holes: the problem is described in the article -- even if it can be achieved from an engineering perspective, and even if the theory is correct, you need to travel to your destination by conventional means to open the wormhole up in the first place.
Alcubierre's warp drive: several problems exist; primarily what is referred to as "negative energy" in the article can be thought of more easily as "negative mass". It's quite likely that no such entity can exist in our universe, we certainly have no idea how to produce it. And you need a lot of it, too. Second, the control problem referred to in the article is much more serious than it sounds. The problem is that the apparatus to control the warp effect would, essentially, need to operate on the unwarped universe outside of the travelling region; based on our current understanding, if the region were travelling at or faster than light, then the rest of the universe would be causally isolated from it, so whoever was travelling inside the warp ship would not be able to control it.
Negative mass: probably can't exist. There's no evidence to support it.
Millis space drives: these have less problems, but aren't actually FTL drives; they're "reactionless" traditional drive systems. This allows you to accelerate to significant fractions of c, but you'll take a while to get there.
The article talked about ideas for potential successor craft. All I have to say is I hope that they are a LOT faster!
Unfortunately, slower would probably allow more accurate measurements. Of course, this has to be weighed against how long it takes to get those measurements, so who knows what eventual decision would be reached?
Can there be binary only drivers or will the GPL interfere?
There can be binary only drivers with no GPL problems. The steps you must take to perform this:
1. Publish an API which is independent of any Linux kernel internals (and is therefore not a derivitive of the kernel and can freely be released under a non GPL license)
2. Make a GPL implementation of it and integrate it into the kernel
3. Make a non-GPL implementation of it. It doesn't need to be fully functional, but while we're at it, it might be useful to have a user space test harness for driver development. This can be BSD (or equivalent) licensed.
Last I checked, the source code was a 40Mb download
Just a quick thought:
jules@colinux:/usr/src> du -s linux-2.6.7/ 264484 linux-2.6.7/
That includes a compiled kernel, but it does mean that to compile a working kernel, you now need over twice as much disk space as an entire working system took up when I first installed Linux.
We don't need an ABI. What we need is a more streamlined kernel config->recompile system. Recompiling your modules should just show up as a progress bar. Debian is pretty good, but it's not 'Utopia' lol. Finding new devices on the system? Just monitor/proc.. you don't need any HAL thing...
The only time this becomes an issue is for binary-only (nvidia hint hint) drivers. Linus is right.
Something needs to be done to streamline the kernel, full stop. Last I checked, the source code was a 40Mb download -- that's over an hour and a half download for me (7K/sec on a modem link).
Seriosuly -- the drivers must be separated from the kernel source. The whole source tree is getting too big to be usable. We need some kind of system that allows you to download a base kernel-source package, a kernel-architecture package for your system, and a set of drivers that include everything you want.
Whether this problem is solved by an ABI or not, I don't really care. It just needs to be solved.
Leave USENET and go talk to a bookseller -- like the GM or owner of a local bookstore. Odds are that they'll be able to backup my statement.
Booksellers don't decide what's a genre and what isn't. They usually file books according to the genre printed on the back of them (normally just above and to the left of the bar code). So, publishers define the genre. And the publishers are led by their editors.
Mods: you might not agree with the parent post, but that doesn't mean it's flamebait. Please think before disagreeing by moderating down, and consider an informed response instead.
Re:this guy WRITES QUIZ SOFTWARE FOR A LIVING
on
They Killed Ken!
·
· Score: 1
I strongly doubt he has a chance to see the questions for the show before it goes live. I would imagine that they are treated as highly confidential, and only entered into the database shortly before the show is filmed, probably only 1 or 2 people other than the question researchers having seen them before this happens. Knowing that a contestant works in a situation where he might have access, they would take extra precautions, probably having an independent auditor on site to make sure procedures are followed correctly. They have to; if any of the other contestants accused him of cheating and they couldn't refute any such claims, it would cost them a lot of money. In fact, it would destroy the credibility of the production company. It would probably be the end of Jeopardy, if that happened.
Re:this guy WRITES QUIZ SOFTWARE FOR A LIVING
on
They Killed Ken!
·
· Score: 2, Insightful
Christ, people, I'm usually the first person to mock the tin foil hat brigade, but don't any of you guys know that the man is employed to write systems for the very quizzes that he's answering questions on? Could that possibly (rather than him being some hero genius to ambition-failing nerds everywhere) explain his winning streak? Isn't this a more reasonable explanation for his fantastic performance than "well, suddenly, this genius just appeared"? Or are dreams nicer to hold on to?
I know you're probably trolling, but: I also have written computer software for a quiz, in my case an Internet pay-to-play one. You don't see me making a fortune off it. Why? Because if I did, I would be scrutinised very closely to ensure I wasn't cheating. If you're right about this contestant (being British, I'd never heard of him until this story -- which I only clicked on because I couldn't work out what it was about), then I doubt he's doing anything even remotely dishonest. In fact, I doubt there is anything dishonest that he could hope to get away with -- someone will almost certainly audit any work he does that ever deals with a live question (or should that be answer?) database.
actually, most of us who saw the original star wars movies in the theaters and would almost certainly get the greedo reference are married now (or have been married).
A number of my married friends have told me that it's the same thing.
Its been a while since I saw the scene in question, but if memory serves it annoyed me -- purely because I had assumed all along that Jabba was actually incapable of independent movement, and therefore the scene just didn't fit with his character for me.
That is a good point, especially with digital cable and satellite being broadcast in MPEG2. I'm not sure if I want to see digital zoom on that.
Perhaps you'd better not try it on DVDs either, 'cause they use MPEG2 as well.
Digital video broadcasts typically use quite high bit rates, and don't have many noticeable compression artifacts, at least not of the "sharp edge around a block" kind that would probably cause a problem for this system.
Lots of people already mentioned, but also one that doesn't seem to have been...
Simon Tatham, author of PuTTY. Which probably qualifies as one of the most commonly used pieces of free software on Windows. He also wrote almost all of NASM (to which I contributed a little), and I've seen his name in the Linux kernel too (to be precise, it was in the VGA console driver code).
If you're ever in Coventry again, I'll buy you a drink.:)
like being caught up by aliens they left behind two seasons ago... aren't they supposed to be trying to get to the alpha quadrant? Doesn't look like they're making much progress!
All the episodes that involved time travel set them back several years worth of progress.
I had a look at the enterprise reruns and just can't get into them.... some of the episodes are so dull I just switch off halfway through. Not surprised they cancelled it, really.
Well, yeah. There have been some truly bad ones. But some good ones, too. And when did I miss the news about it being cancelled? I thought it had been renewed...
I had such high hopes for Voyager, and that was a let down (I've maybe seen 10 episodes). I had such high hopes for Enterprise, and I think I only watched the pilot.
I'd suggest actually watching more before berating them too much. Yes, Voyager wasn't brilliant. They did miss an opportunity to actually turn it into a story rather than just a series of individual episodes, but there were some good points. A fair few of the stories were well written. Some of the characters were interesting, at least for a few series.
Enterprise isn't as good as Voyager, that is true. But even Enterprise has its share of episodes that don't suck, and few that are truly dire. I mean, OK, they've done a couple of episodes that had "this never happened" endings, which I have to agree is _the_ _most_ _lousy_ trick in the book.
So neither of them were up to the standard of Firefly. But then neither was DS9, IMO.
I think what they need to do is get some good writers in, let them play around with ideas for characters and stories for a year or so before committing to anything, then write a few stories, put together a series manual, and ask established modern SF writers to write the rest of the series. The problem with modern trek is that Berman & Co are writing so much of it. Who wants to watch hour after hour of the same writer doing stuff with the same characters? It gets boring quickly, even when the writer's good.
I've always thought this was a daft name. Open windows aren't particuarly useful -- they're just like a hole, really, whereas a closed window keeps the wind and rain out while you can still see through it.
The Windows kernel structure isn't like that. A bug check, or BSOD isn't because something has erased the entire kernel, it's because something *might* possibly have begun to go amiss... It is that policy that makes that an uncought exception by a any code raises a BSOD. As well as running at an IRQL that is not appropriate. In fact, those two reasons are the most common BSOD reasons.
Actually, that's pretty much my point - they can prevent BSODs by changing the way the kernel behaves when it detects the conditions that cause them.
On a side note: is it still that way in linux now that the kernel is pre-emtible/interruptible (like NT has always been) ?
I think so, yes. I've not done much kernel development since the switch, but it didn't look like the changes were too major.
They're something that's easy to define, work well in MacOSX and Windows XP, and don't work very well in (some) current X11 servers. So obviously, you're going to get loads of graphics geeks rushing to fix it.
That said, the drop shadows in KDE on XFree86 look fine to me already.
Slashdot Mirror
What sets off the BS detector for me is the APIs. They consistently state that they can do this for any OS.
Actually, it seems to be primarily other people saying this. Read their site; they only claim to be able to do it for UNIX-like systems.
There are big problems with all of these techniques.
Worm holes: the problem is described in the article -- even if it can be achieved from an engineering perspective, and even if the theory is correct, you need to travel to your destination by conventional means to open the wormhole up in the first place.
Alcubierre's warp drive: several problems exist; primarily what is referred to as "negative energy" in the article can be thought of more easily as "negative mass". It's quite likely that no such entity can exist in our universe, we certainly have no idea how to produce it. And you need a lot of it, too. Second, the control problem referred to in the article is much more serious than it sounds. The problem is that the apparatus to control the warp effect would, essentially, need to operate on the unwarped universe outside of the travelling region; based on our current understanding, if the region were travelling at or faster than light, then the rest of the universe would be causally isolated from it, so whoever was travelling inside the warp ship would not be able to control it.
Negative mass: probably can't exist. There's no evidence to support it.
Millis space drives: these have less problems, but aren't actually FTL drives; they're "reactionless" traditional drive systems. This allows you to accelerate to significant fractions of c, but you'll take a while to get there.
The article talked about ideas for potential successor craft. All I have to say is I hope that they are a LOT faster!
Unfortunately, slower would probably allow more accurate measurements. Of course, this has to be weighed against how long it takes to get those measurements, so who knows what eventual decision would be reached?
Is it too late to contribute to the openBSOD project...?
That'd be ReactOS, then. I hear they're looking for help.
Can there be binary only drivers or will the GPL interfere?
There can be binary only drivers with no GPL problems. The steps you must take to perform this:
1. Publish an API which is independent of any Linux kernel internals (and is therefore not a derivitive of the kernel and can freely be released under a non GPL license)
2. Make a GPL implementation of it and integrate it into the kernel
3. Make a non-GPL implementation of it. It doesn't need to be fully functional, but while we're at it, it might be useful to have a user space test harness for driver development. This can be BSD (or equivalent) licensed.
4. Write binary drivers.
5. ???
6. Profit
Last I checked, the source code was a 40Mb download
Just a quick thought:
jules@colinux:/usr/src> du -s linux-2.6.7/
264484 linux-2.6.7/
That includes a compiled kernel, but it does mean that to compile a working kernel, you now need over twice as much disk space as an entire working system took up when I first installed Linux.
We don't need an ABI. What we need is a more streamlined kernel config->recompile system. Recompiling your modules should just show up as a progress bar. Debian is pretty good, but it's not 'Utopia' lol. Finding new devices on the system? Just monitor /proc.. you don't need any HAL thing...
The only time this becomes an issue is for binary-only (nvidia hint hint) drivers. Linus is right.
Something needs to be done to streamline the kernel, full stop. Last I checked, the source code was a 40Mb download -- that's over an hour and a half download for me (7K/sec on a modem link).
Seriosuly -- the drivers must be separated from the kernel source. The whole source tree is getting too big to be usable. We need some kind of system that allows you to download a base kernel-source package, a kernel-architecture package for your system, and a set of drivers that include everything you want.
Whether this problem is solved by an ABI or not, I don't really care. It just needs to be solved.
Leave USENET and go talk to a bookseller -- like the GM or owner of a local bookstore. Odds are that they'll be able to backup my statement.
Booksellers don't decide what's a genre and what isn't. They usually file books according to the genre printed on the back of them (normally just above and to the left of the bar code). So, publishers define the genre. And the publishers are led by their editors.
Here's what one well known editor in the SF field has to say on the matter.
I'll leave people to draw their own conclusions.
Mods: you might not agree with the parent post, but that doesn't mean it's flamebait. Please think before disagreeing by moderating down, and consider an informed response instead.
I strongly doubt he has a chance to see the questions for the show before it goes live. I would imagine that they are treated as highly confidential, and only entered into the database shortly before the show is filmed, probably only 1 or 2 people other than the question researchers having seen them before this happens. Knowing that a contestant works in a situation where he might have access, they would take extra precautions, probably having an independent auditor on site to make sure procedures are followed correctly. They have to; if any of the other contestants accused him of cheating and they couldn't refute any such claims, it would cost them a lot of money. In fact, it would destroy the credibility of the production company. It would probably be the end of Jeopardy, if that happened.
Christ, people, I'm usually the first person to mock the tin foil hat brigade, but don't any of you guys know that the man is employed to write systems for the very quizzes that he's answering questions on? Could that possibly (rather than him being some hero genius to ambition-failing nerds everywhere) explain his winning streak? Isn't this a more reasonable explanation for his fantastic performance than "well, suddenly, this genius just appeared"? Or are dreams nicer to hold on to?
I know you're probably trolling, but: I also have written computer software for a quiz, in my case an Internet pay-to-play one. You don't see me making a fortune off it. Why? Because if I did, I would be scrutinised very closely to ensure I wasn't cheating. If you're right about this contestant (being British, I'd never heard of him until this story -- which I only clicked on because I couldn't work out what it was about), then I doubt he's doing anything even remotely dishonest. In fact, I doubt there is anything dishonest that he could hope to get away with -- someone will almost certainly audit any work he does that ever deals with a live question (or should that be answer?) database.
actually, most of us who saw the original star wars movies in the theaters and would almost certainly get the greedo reference are married now (or have been married).
A number of my married friends have told me that it's the same thing.
Its been a while since I saw the scene in question, but if memory serves it annoyed me -- purely because I had assumed all along that Jabba was actually incapable of independent movement, and therefore the scene just didn't fit with his character for me.
That is a good point, especially with digital cable and satellite being broadcast in MPEG2. I'm not sure if I want to see digital zoom on that.
Perhaps you'd better not try it on DVDs either, 'cause they use MPEG2 as well.
Digital video broadcasts typically use quite high bit rates, and don't have many noticeable compression artifacts, at least not of the "sharp edge around a block" kind that would probably cause a problem for this system.
Lots of people already mentioned, but also one that doesn't seem to have been...
:)
Simon Tatham, author of PuTTY. Which probably qualifies as one of the most commonly used pieces of free software on Windows. He also wrote almost all of NASM (to which I contributed a little), and I've seen his name in the Linux kernel too (to be precise, it was in the VGA console driver code).
If you're ever in Coventry again, I'll buy you a drink.
How do you say 'ironic' in Klingon?
That would be "SlashbotHiveMind". Or maybe Q'Ghaqrxla'ptah. I might be getting confused.
like being caught up by aliens they left behind two seasons ago... aren't they supposed to be trying to get to the alpha quadrant? Doesn't look like they're making much progress!
All the episodes that involved time travel set them back several years worth of progress.
I had a look at the enterprise reruns and just can't get into them.... some of the episodes are so dull I just switch off halfway through. Not surprised they cancelled it, really.
Well, yeah. There have been some truly bad ones. But some good ones, too. And when did I miss the news about it being cancelled? I thought it had been renewed...
I had such high hopes for Voyager, and that was a let down (I've maybe seen 10 episodes). I had such high hopes for Enterprise, and I think I only watched the pilot.
I'd suggest actually watching more before berating them too much. Yes, Voyager wasn't brilliant. They did miss an opportunity to actually turn it into a story rather than just a series of individual episodes, but there were some good points. A fair few of the stories were well written. Some of the characters were interesting, at least for a few series.
Enterprise isn't as good as Voyager, that is true. But even Enterprise has its share of episodes that don't suck, and few that are truly dire. I mean, OK, they've done a couple of episodes that had "this never happened" endings, which I have to agree is _the_ _most_ _lousy_ trick in the book.
So neither of them were up to the standard of Firefly. But then neither was DS9, IMO.
I think what they need to do is get some good writers in, let them play around with ideas for characters and stories for a year or so before committing to anything, then write a few stories, put together a series manual, and ask established modern SF writers to write the rest of the series. The problem with modern trek is that Berman & Co are writing so much of it. Who wants to watch hour after hour of the same writer doing stuff with the same characters? It gets boring quickly, even when the writer's good.
Because some geeks like transparent terminal windows.
Simple, really.
Sun [calls] their version of X11R6 OpenWindows
I've always thought this was a daft name. Open windows aren't particuarly useful -- they're just like a hole, really, whereas a closed window keeps the wind and rain out while you can still see through it.
Just a thought.
Yes. You perceive how far away from you the monitor is.
Firstly, I have 2 eyes, so I can already do depth.
2 eyes only help depth perception when the images they see are different; with a standard computer monitor, this isn't the case.
Did you read mine. I answered in my first paragraph -- they care because its something that Windows & MacOS do better, and because it's easy to fix.
The Windows kernel structure isn't like that. A bug check, or BSOD isn't because something has erased the entire kernel, it's because something *might* possibly have begun to go amiss... It is that policy that makes that an uncought exception by a any code raises a BSOD. As well as running at an IRQL that is not appropriate. In fact, those two reasons are the most common BSOD reasons.
Actually, that's pretty much my point - they can prevent BSODs by changing the way the kernel behaves when it detects the conditions that cause them.
On a side note: is it still that way in linux now that the kernel is pre-emtible/interruptible (like NT has always been) ?
I think so, yes. I've not done much kernel development since the switch, but it didn't look like the changes were too major.
Really, why?
What is it with drop shadows?
They're something that's easy to define, work well in MacOSX and Windows XP, and don't work very well in (some) current X11 servers. So obviously, you're going to get loads of graphics geeks rushing to fix it.
That said, the drop shadows in KDE on XFree86 look fine to me already.