I hate to rain on your parade, but Windows is not a realtime OS. All that BS you spewed about how RT priority will make everything all perfect is just that: BS. Windows makes no such guarantee, and the process will be pre-empted and experience indeterminate latencies even with RT priority set.
You're simply wrong. Sorry. No, Microsoft did not code their OS to support skip-free sound.
In case anyone is wondering, Linux (at least without patches) is not an RTOS either. None of the popular operating systems are, because real time is not efficient. RT-priority threads in Linux are also not guaranteed to work. However, with the low-latency (or possibly preempt) patches, Linux is good enough for anything media-related (though maybe not for controlling surgical robots or something - you could use RTLinux for that).
Of course, the catch with all of this is that RT guarantees only mean anything if the application is specifically designed to make use of them. Setting a program to realtime priority absolutely does not mean it'll work right. It has to be designed to use realtime priority - which very, very few apps are.
So, to make a long story short, you, sir, are full of shit.
People do this in Seattle. It's especially common in Redmond on certain corporate campuses, 'cause the freeway back to Seattle from there is especially horrific.
The problem with it is that they mostly pick people up at bus stops, which doesn't help anyone.
The New nvidia graphics installer (4369) comes with a new installer that will either d/l the appropriate pre-compilled driver, OR d/l the sources and compile a driver for you... all you need is the kernel-source installed for your current kernel...
That's not the driver it's recompiling. It's recompiling a wrapper layer around the driver that interfaces between it and the kernel.
The actual driver is completely closed-source. It may work with multiple kernels as long as the wrapper compiles, but there's no guarantee of that and it still can't be debugged or audited for security or anything.
And considering the bizaare circumstances that created life on earth was astrnomically rare (no pun intended:P)only created one sentient lifeform here that we know of the chance of meeting intelligent life in this universe is near null.
Do you have a statistical analysis of thousands or millions of planets in the galaxy encompassing whether life developed there and whether intelligent life evolved, including the average lifetime of the intelligent species etc.?
If not, you shouldn't talk about chance, since you don't have enough data to make a judgement. This is a classic error in things like the Drake Equation - it's all nice and good to come up with a couple "reasonable" guesses and make far-reaching claims about the probability of aliens, but the truth is we really don't know.
We've never met any aliens, but we've also never been to any other star systems. For all we know, Alpha Centauri could be teeming with aliens, who're just keeping a low profile so as not to startle us. Or, alternatively, the nearest alien intelligence could be a billion light-years away. We have no data.
We certainly haven't visited thousands of star systems to determine the likelihood of earth-like planets in our galaxy (though with a big enough interferometer, we may not need to). We haven't visited thousands of earth-like planets to see how likely life is to form. We haven't visited thousands of planets with life to determine how likely they are to contain intelligent species. Etc. We don't even know how common earth-like life is compared to other possible chemical bases, or robotic life, or whatever. We can theorize, but we don't have any actual measurements.
We have a few theoretical ideas based on astrophysics - for instance, there's a modern idea that maybe the galaxy is fairly inhospitable outside of a particular life zone we happen to be in (based on distance from the core) because of stellar age / asteroids / etc. And we know that if aliens are transmitting "Hello!" on big radio beacons, they're not being too obvious about it since our cursory SETI searches didn't just run across them immediately. But that's about it.
"Ironically, Duke3d has been running on win32 operative systems since the beginning. The tweaks to get the it working has been around about as long."
Ironically, Duke3d on windows runs under the DOS emulator. Linux also has a DOS emulator, and Duke3d has run under that (with sound even) for about as long.
What's with all the comments, "This is total bullsh*t! April Fools! Complete crap!" ?
Did anyone actually read the link to the whitespace language? Anyone? Hello? I mean, I know, I know, nobody on/. reads the articles, but this is ridiculous.
It's real! The description of the syntax is a masterwork of stunning proportions!
This is exactly what April Fools is supposed to be about! It's real! It's just... silly.
Your mfree() function is completely useless, except in as much as it's an alias for free(). (An exact alias, free() is defined as a no-op on a null pointer)
What sort of insane "conservationist" would oppose strip-mining the moon to absolutely any degree possible (short of perhaps changing the pretty way it looks to the naked eye, and then you just mine the far side).
I don't understand this. Is there even a question here? I've heard this before. Did everyone who thinks about this question do a whole lot of drugs before talking about it, or what?
The moon is a hunk of rock. There is no life there, thus, there is no environment. At all. There is nothing to conserve, other than perhaps a few pretty rock formations visible from earth that are so large we couldn't mess them up if we tried.
So, what's the question here? I don't understand it. How could anyone who's not clinically insane even begin to try to build a case that mining the moon, if it's economically viable at all, is a bad thing?
Hello? The moon (and space in general) has no environment. It is fundamentally impossible to pollute it. Essentially anything we do there is just fine.
Case study: What if you've got some hot plutonium goop mixed with nerve gas, botulin, dioxin, and Britney Spears CD's which you just dug out of a reactor core on the moon? If you're wondering what you should do with it... Let's see, what can you do without causing horrible environmental damage? Hmm...
You could:
Expensively reprocess it, and bury it in a special mine for $900 trillion.
Put it in a big box and bury it in a special bunker for $1 billion.
Put it in a $0.10 Hefty cinch sack, slap a sticker on it that reads "radioactive" and throw it out the back door next to your old '76 Moon Pinto.
Which option pollutes less? Guess what? They're all basically equivalent! There's no environment to pollute!
Yes, it really is that simple. Strip mine the moon and build factories on it until it's nothing but a giant cesspool of industrial waste - WHO CARES?! It's the moon! There's nothing there!
You can compile Java directly to machine code which runs without an interpreter too. Compiled vs. Interpreted is not the same as how high level the language is.
And actually, it doesn't compile "directly" to machine code. It's compiled into some sort of compiler-specific intermediate form where it gets optimized, and then output as machine-specific assembly. The assembler is the tool which creates machine code.
It's quite possible to compile almost any interpreted language to a machine executable, if you really want to. Some may be quite inefficient, of course. It's also possible to run any language in an interpreter.
The distinction between a high level and a low level language is very fuzzy, and roughly refers to the level of abstraction it provides for abstract data types, objects, memory management, etc.
C is a "mid-level" language, because it doesn't provide native support for objects, lists, trees, garbage collection, etc. However, it can certainly support all of these with the proper libraries (except garbage collection, which is more difficult - you need some compiler support too generally, but it's possible).
Java, on the other hand, is considered somewhat higher-level, because it provides native object and garbage collection support, and standard library support for many data types. It also attempts to place stronger guarantees on the consistency of the runtime state.
Other languages, such as python or perl, might be considered higher level still, with intrinsic list and associative array support, etc. So could lisp.
But then, the whole high/low level thing is extremely fuzzy. For instance, lisp supports garbage collection, arrays, etc., as well as closures, lambda functions, runtime code generation, etc., all very high level. But it doesn't natively support objects. So, an OOP person might laugh at it with disdain, especially since it's basically the oldest language still in use.
C++ also supports a medly of "high level" features (some relatively unique), but lacks garbage collection and the sort of strong internal consistency guarantees interpreted languages provide, so some people scoff at its high-level-ness as well. And of course, you can fiddle with memory locations directly if you want and play with inline assembly as well.
In terms of this sort of discussion, the relevant comparison was about the wordiness of the respective languages. But of course, this is also a completely deceptive comparison, since you have to ensure they're doing precisely the same thing. If you select a task where one of them comes with a library that does exactly that, and the other one doesn't, you can easily make any language look far more concise than any other.
For instance, say I make a language, asm-foo, which is assembly except, I include the function, foo, which takes no arguments. foo will automatically run a GUI based office suite on the current display which allows the user to perform a number of tasks.:-)
Here is my office suite software, in hand-optimized intel x86 asm-foo assembly code:
.text .globl main
main:
call foo
ret .end main
Please show me another language besides asm-foo where I can write an office suite more easily.:-)
You do realize, every single thing you've stated is already done by linux, automatically, only about a million times better than the way you propose doing it, right?
What we need is something similiar to dlls in which an application linked to an earlier version of a dll can use the newer one and still function.
Oh, you mean, like, say, maybe, er, um, say, a shared library? Oh, wait, what's that? You mean, Linux has those? And in fact, it even supports versioning of them, so if you have two applications which require incompatible versions of the same library, they can still work too, unlike Windows? I'm shocked! Shocked I say!
We also need a special daemon or a super init which can keep track of versions of different applications and so's. With this installed it can be possible to remove an application and still have another application that requires one of the libraries or so's to still function. The daemon would only remove certian parts of the package but not all of the files from a package.
This is a ridiculous idea. Wouldn't it be better to just have a program which keeps track of which libraries a program needs, and not remove them if they're needed by something? A program which manages all the application files on your system, and handles interdependencies and conflicts automatically? Maybe we could bundle the files together into, oh, I dunno, packages, and call this a Package Manager. Wait, that's an amazing idea! I should patent it!
Wait, I have an even more shocking idea. What if, say, I wanted to upgrade a library that's in use by a program that's running right now. Wouldn't it be great if I could atomically drop the new library over the old one, and let any programs that are still using the old one keep using it until the last program using it exits, at which point the library is automatically deleted by the OS? Wouldn't that be a shockingly cool idea? New programs would get the new library, old ones would still have the original to use until they shut down! That way, I could upgrade live, running software and have it actually work! I should patent that too!
Oh wait, what's that, what's that you say? Linux does all this, already, automatically, and in fact, has done it for years and years? I'm shocked! Shocked I say!
You don't support code, you support the binary you shipped.
Nothing would stop some idiot from making a mod, distributing it wildly, and then have every one calling *your* tech support for help.
Nothing would stop some idiot from making a binary patch to your app *cough* crackers do this today to every app *cough* and distributing it wildly, and then have everyone calling your tech support for help. Your point?
Only in the same way that Tom Clancey's competitors can take advantage of reading his books.
Wrong, wrong, wrong. The only way I can take advantage of a Tom Clancy book is if I:
A) Tear the cover off and try to sell it anway
or
B) Retype the whole damn thing from scratch
Software is much easier to copy - a bit of compiling, and bingo - there you go.
Ever heard of a Xerox machine? A scanner? Having the source or not having the source has absolutely no effect of any kind or form whatsoever on the meaning of copyright.
And you're right, software is easy to copy. Exactly how is software in binary form harder to copy than in source form, again?
And since competitors would be required to disclose source as well, violations would easily be detected.
Hey, free engineering for a weekend of changing variable names and the odd alogrithm? Geez, thats too much for me to handle. I better give up this source code and pay somebody else for the binaries.
I see you've never taken a CSE class at a university. Software exists which will take two code bases, possibly with completely different names and formatting, and decompose them into structural parse trees and compare those for signs of copying.
It's a lot easier to do this if you have the source code, of course.
Totally wrong. The only reason detachment was hard for X is because the designers didn't plan for it. In a higher level system, you could not only detach more easily, but with less wasting of resources. There'd be no need to maintain bitmapped images of all your programs when they're not in use- the GUI system can regenerate those when the user next becomes active.
The reason it'll be more difficult is because more state is being held on the server side, which will have to be pushed back to the clients (which were supposed to be super-simple) and then restored to the new server somehow. Building it into the protocol is of course possible, but that will inherently break the simplicity requirements of the design.
Consider. Say I have an application that opens an edit widget, and the user types in part of a document, with particular formatting, etc. Under the "very high level" approach, the server will just pop up an edit widget here and everything will happen on the server side. At particular points, the server will synchronize with the client, say when the user hits a special button which does something useful. Many parts of the display need never be sent back to the client under this approach, such as the entirety of the internal state of the widget - that was the point of the design, after all, in that internal drawing state of the widgets doesn't go over the wire.
Now, consider this with the arbitrary disconnect requirement. The wire may be cut at any time, and the client side app is expected to have enough data to rebuild its UI on a new server in exactly the same way. This is an inherent limitation, because it means that all of the internal state changes of every server widget needs to be transmitted back to the client immediately, and in addition, all the server-side widgets have to be stateless (they have to support reconstruction at any point). Suddenly, your protocol is a whole lot more chatty.
This also means that the clients are much more complex. They can't be elegantly simple any more, because they have to replicate the entire widget state from the server at all times. You effectively end up with both ends running a copy of the widget set, which of course, means that you can't dramatically re-theme them on the server, because that requires a protocol change. Ouch!
The alternative, of course, is to do it like X11, and run a special proxy server on the client side, which stores all the state locally and knows how to talk to a remote server to reconstruct it. This will be quite involved, especially if the protocol doesn't support completely stateless widgets - it might have to run through some virtual user operations on a widget just to restore its state. This looks like xmove, of course, only even more complex.
Of course, if you do that, why even bother? You could get the same benefits (if any) by just making a protocol extension to X11 for GTK, which is only implemented inside of xmove. GTK apps would detect a special X server, describe their GUI using the new method, and then the special server and special clients could communicate through a special, higher level protocol. Non-gtk apps could go through standard X calls, or a bitmap scheme like vnc.
Once you start doing that though, you've no longer got "X11". Eliminate any part of the protocol, and the backwards compatibility that is X11's biggest advantage is gone. You'd be essentially creating a new protocol by reusing X's ideas and code. That would be an even harder sell to the app developer community, because in the end it varies so little from existing X.
The migration difficulty in developing a new version of the X11 protocol (X11R7?) and updating all the apps to not use the deprecated features would be far less than developing a new system from scratch. If done carefully, deprecated features would be available through a module during the migration period. At the same time, new features which are available through extensions would simply be merged back as part of the main protocol. This sort of thing takes a while, but it could be done and would be far less painful.
Of course, whether it's worth doing is another matter. Probably not, because X works fine for now. But it's a more viable course to take than replacing X from scratch.
Ever try running X11 programs across the modern internet? It's very painful (unless you have some amazingly fat fast pipe). A simple "ls" in a remotely displayed xterm seems to take forever. But yet, gorgeous online games like Counterstrike and Warcraft are fast and snappy. Of course this is because the games are communicating at a much higher level than the X drawing primitives do. With newer, higher-level GUI APIs, more applications might be able to get this kind of benefit. It all depends on where in the application you define the partition between stuff running on the client and the server. PicoGui tries to run more of the GUI parts on the client-side, reducing the bandwidth needed to keep the program going.
I run X11 programs over the internet all the time. It works fine, and is perfectly usable. Just use ssh -C -X, and it compresses the protocol stream. Or, you can use one of the protocol compressors. This is even somewhat usable over a modem, though I don't use those any more.
Ironically enough, there is a remote connection system that's even faster and snappier, though: TightVNC. With 8-bit mode and compression, it's completely usable and has almost no discernible latency over my cable modem line. Why is this ironic, you ask? It's ironic because it's exactly the opposite of your point: It's even *lower level* than X11, since it takes bitmap snapshots of the display and sends those! X11 at least has the good sense to send high level drawing primitives like rectangles!
What this goes to show is, one size does not fit all. One solution is not best in all situations.
Another useful example of this principle is when you consider moving applications between displays (or detaching them completely). This is a very nice thing to do, and is very easy with VNC, since no state is stored in the client. It's much less easy to do in X11, since you end up needing to use a quite complex protocol adaptor which actually is a whole server in itself to accomplish the same thing (since it has to remember all the state). In an even higher level system like picogui, this will be even harder still.
X11 is a good system and works fine. There just isn't a compelling reason to dump it. A much better idea might be to invest in some cleanup efforts in X11 itself. For instance, the protocol is rather old and is becoming somewhat more crufty with time. Perhaps it can be improved and cleaned up with some careful thinking.
On the other hand, the central point that was completely missed (as usual) in this/. discussion is that this doesn't mean picogui is bad. One size does not fit all - meaning, X11 may actually not be the best solution on your palm pilot!
For the WineX supported games (eg. WCIII, The Sims) the performance will be reduced significantly, but it'll generally still be ok. This is still being worked on - there will probably always be a small amount of overhead if the game uses Direct3d, but other than that, there's no inherent technical reason that it should be slower under Linux (so consider this a bug).
For native games, such (eg. NWN (we hope), and UT2k3) the performance is pretty much identical if you're using an NVidia card. Well, identical or a little faster than windows, usually. The NVidia drivers are basically the same for Linux and Windows, but at least some games (eg. Quake3) have benched a bit faster under Linux.
Linux supports HT. No OS as far as I know sees much benefit from it.
The difference between a "process" and a "thread" is pretty small. A thread is just a process with shared page tables, for the most part. This means that there's less overhead switching between two threads, since you don't have to flush the TLB and caches. The processor per se knows absolutely nothing about any of this - it just knows when the OS commands it to flush the TLB and the caches, and change the page table addresses.
The basic point of HT is that it's sort-of another CPU, but it's just leeching unused resources from the main CPU. So, the scheduling logic in the OS needs to understand that it's not a real CPU, and thus should be grouped with the real CPU it's associated with. Linux 2.5/2.6 will support these tweaks, with 2.4 you'll need some sort of patch currently. Without the tweaks, you still get HT, it just doesn't help much.
But really, it never helps that much. Don't expect a 2x speedup or anything, even if your system is running heavily threaded applications.
To be more specific, you can't go beyond 2-3GB per process using intel, at least, directly. (You could access more indirectly, just not as actual memory.)
The reason is that the kernel needs memory too. Say you try to load some data from disk. You call the read() system call, which switches to the kernel execution context. The kernel then checks to see if the data you're trying to read is available in the disk cache. If it is, it copies. If it's not, it schedules a load, puts your process to sleep, and when the load finishes, it copies.
So, basically, either way, the kernel needs to be copying data from the disk cache to your program's memory space. This means, it needs to see both at once!
The standard way this works is, all physical memory (which might be used as cache) is mapped into the kernel, normally limited to the high 1GB. The user process gets the low 1GB. So, when you switch to kernel mode, the kernel has all memory, physical and program-virtual, available to it.
Now, some people have more than 1GB ram. The easiest thing for these people to do is use a 2/2 split, if they only have 2GB. This means the process can't use more than 2GB at once, but usually that's ok because most programs don't need that, really. A 1/3 split is also possible.
However, obviously no straight split scheme like this is going to work if you install 4GB of ram! Instead, the kernel is going to have to play some trickery with the page tables and segment registers to get access to this extra memory. This way, it can support more than 1GB, up to 64. The user process of course is still limited to 3.
The problem here, of course, is that doing tricks to get access to your memory in the kernel is obviously going to be slow. So, a kernel that actually tries to use more than about 1 (or maybe 2) GB of ram will be slower than a kernel which does not, and this is unavoidable. Now, this may be just fine, because that extra ram can be used for disk cache - and if your program uses a stupendous amount of disk space, even if the kernel is slower, the huge disk cache will still be a big help for you.
But to make a long story short, >1 (or at most, 2) GB of ram will actually make your computer slower, unless you actually do something which uses all of that ram.
None of this would be true, of course, on a 64-bit machine.
Re:The Before and after shots look backwards
on
Font HOWTO For Linux
·
· Score: 1
It's not just you. Well, except that the second one actually does look better, really...
Look at them under a magnifier. The first screenshot (the before) has antialiasing turned on. You can also tell this by looking at the 2 at the bottom. It's been antialiased into complete garbage, and is missing an entire stroke.
The second screenshot (after) has antialiasing turned off. This means that the spacing is a little less well-hinted, but on the other hand, you can at least see the strokes, and it doesn't look that blurry.
One obvious, and unarguable example of this, is when a law is not a law.
For instance, when congress passes a law stating that it's illegal to publish an article in a newspaper, that law is not a law in the USA. It's just some meaningless verbiage they spewed out on paper to show their own incompetence. Why? Because the constitution says they can't do that.
Now, the cops can arrest you for that, but in doing so, they're themselves violating the law by performing a false arrest. (It so happens that they can't be punished for it, but in effect, they are). Now, obviously, if everyone cowered in fear from the big mean police and never attempted to utilize their rights, it would be as if those rights didn't exist. So clearly, you have the duty to disobey, or at least (if the issue is irrelevant to you) simply ignore an illegal law.
Now, as for a simply unjust law, things aren't quite so obvious since it's certainly possible that a law is legal, but simply absurd. But then, you have to consider that laws are made by people, and can say anything at all. There are no inherent checks on them - so clearly, not all laws should be, or can be, obeyed. For instance, a law ordering you to rob your neighbors and give their property to your local police department is one you have a duty to disobey, even if it wasn't obviously illegal. Er, oh wait, that's basically what the RICO laws state, and the supreme court found them to be within the law. I guess that law actually is legal. Should you obey it?
Writing a PPC emulator is not a big deal. Emulating any processor ISA on any other is not a big deal. You can write one in C that's fully cross platform and works anywhere, even.
Emulating the whole system so it can run full OS software is much harder, since you have to emulate a lot more than just the CPU. There's nothing special about macs here - in fact, it would be easier since they're rather standardized - it's just more to do.
The problem with emulation isn't that it's hard. It's not. It's that it's slow. Writing a fast emulator for a PPC chip on an x86 would be quite difficult. Of course, this goes for any other chip, not just the PPC, as well. The x86 chips are actually harder to emulate, because they're so bizarre and badly designed, in truth.
The reason PPC Mac emulators are hard to find is because nobody wants one. There a strong demand for emulators to run software that won't run otherwise. There's very little Mac software in that category, so hardly anyone wants an emulator for them. At least, they don't want one bad enough to write it.
It is true that oil is dirty. However, it's also true that we're not going to run out.
The alternatives the previous poster mentioned are already being worked on.
Basically, what's going to happen is that as oil reserves are depleted, the price will increase. Eventually, it will rise above the price of alternative sources of oil.
What are these alternative sources? Well, for starters, it's possible to refine oil from coal. This process is more expensive than just pumping it out of the ground, so we don't do it right now. When the price of oil rises enough, it will make more sense to use coal.
There's a lot of coal in the world.
When the coal runs down, after a few thousand years, the price will again start to rise a bit, at which point a second alternative will be attractive, if it isn't already: oil shale.
When the oil shale runs out, after many more millennia, we'll either find a new energy-rich source, or we'll go full synthetic. Of course, full synthetic production will run at an energy loss, so it will need a real power source such as solar or nuclear power to drive it.
Synthetic oil production will be viable for more or less the lifetime of the universe.
One example of a form of "synthetic" oil production here is refined vegetable oil, by the way. Solar powered crops can be replanted every year, and thus won't run out.
Of course, actual oil from the ground won't run out either. It's just that new reserves won't form at nearly the rate we like to use it, so it'll always be insufficient to fill demand after the current fields are depleted.
So, no, we'll never "run out" of oil.
We will, on the other hand, want to stop using it because it's dirty long before we reach synthetic production. When we actually do stop using it, who can say?
Slashdot Mirror
I hate to rain on your parade, but Windows is not a realtime OS. All that BS you spewed about how RT priority will make everything all perfect is just that: BS. Windows makes no such guarantee, and the process will be pre-empted and experience indeterminate latencies even with RT priority set.
You're simply wrong. Sorry. No, Microsoft did not code their OS to support skip-free sound.
In case anyone is wondering, Linux (at least without patches) is not an RTOS either. None of the popular operating systems are, because real time is not efficient. RT-priority threads in Linux are also not guaranteed to work. However, with the low-latency (or possibly preempt) patches, Linux is good enough for anything media-related (though maybe not for controlling surgical robots or something - you could use RTLinux for that).
Of course, the catch with all of this is that RT guarantees only mean anything if the application is specifically designed to make use of them. Setting a program to realtime priority absolutely does not mean it'll work right. It has to be designed to use realtime priority - which very, very few apps are.
So, to make a long story short, you, sir, are full of shit.
People do this in Seattle. It's especially common in Redmond on certain corporate campuses, 'cause the freeway back to Seattle from there is especially horrific.
The problem with it is that they mostly pick people up at bus stops, which doesn't help anyone.
That's not the driver it's recompiling. It's recompiling a wrapper layer around the driver that interfaces between it and the kernel.
The actual driver is completely closed-source. It may work with multiple kernels as long as the wrapper compiles, but there's no guarantee of that and it still can't be debugged or audited for security or anything.
Do you have a statistical analysis of thousands or millions of planets in the galaxy encompassing whether life developed there and whether intelligent life evolved, including the average lifetime of the intelligent species etc.?
If not, you shouldn't talk about chance, since you don't have enough data to make a judgement. This is a classic error in things like the Drake Equation - it's all nice and good to come up with a couple "reasonable" guesses and make far-reaching claims about the probability of aliens, but the truth is we really don't know.
We've never met any aliens, but we've also never been to any other star systems. For all we know, Alpha Centauri could be teeming with aliens, who're just keeping a low profile so as not to startle us. Or, alternatively, the nearest alien intelligence could be a billion light-years away. We have no data.
We certainly haven't visited thousands of star systems to determine the likelihood of earth-like planets in our galaxy (though with a big enough interferometer, we may not need to). We haven't visited thousands of earth-like planets to see how likely life is to form. We haven't visited thousands of planets with life to determine how likely they are to contain intelligent species. Etc. We don't even know how common earth-like life is compared to other possible chemical bases, or robotic life, or whatever. We can theorize, but we don't have any actual measurements.
We have a few theoretical ideas based on astrophysics - for instance, there's a modern idea that maybe the galaxy is fairly inhospitable outside of a particular life zone we happen to be in (based on distance from the core) because of stellar age / asteroids / etc. And we know that if aliens are transmitting "Hello!" on big radio beacons, they're not being too obvious about it since our cursory SETI searches didn't just run across them immediately. But that's about it.
You mean lost. Sure, they won in court, but it turned out, they couldn't compete with Microsoft politically.
Microsoft can do whatever it pleases now, it knows the government is a paper tiger.
Ironically, Duke3d on windows runs under the DOS emulator. Linux also has a DOS emulator, and Duke3d has run under that (with sound even) for about as long.
What's with all the comments, "This is total bullsh*t! April Fools! Complete crap!" ?
Did anyone actually read the link to the whitespace language? Anyone? Hello? I mean, I know, I know, nobody on /. reads the articles, but this is ridiculous.
It's real! The description of the syntax is a masterwork of stunning proportions!
This is exactly what April Fools is supposed to be about! It's real! It's just... silly.
This is a troll, right?
Your mfree() function is completely useless, except in as much as it's an alias for free(). (An exact alias, free() is defined as a no-op on a null pointer)
The monkey is harder to render :-)
What sort of insane "conservationist" would oppose strip-mining the moon to absolutely any degree possible (short of perhaps changing the pretty way it looks to the naked eye, and then you just mine the far side).
I don't understand this. Is there even a question here? I've heard this before. Did everyone who thinks about this question do a whole lot of drugs before talking about it, or what?
The moon is a hunk of rock. There is no life there, thus, there is no environment. At all. There is nothing to conserve, other than perhaps a few pretty rock formations visible from earth that are so large we couldn't mess them up if we tried.
So, what's the question here? I don't understand it. How could anyone who's not clinically insane even begin to try to build a case that mining the moon, if it's economically viable at all, is a bad thing?
Hello? The moon (and space in general) has no environment. It is fundamentally impossible to pollute it. Essentially anything we do there is just fine.
Case study: What if you've got some hot plutonium goop mixed with nerve gas, botulin, dioxin, and Britney Spears CD's which you just dug out of a reactor core on the moon? If you're wondering what you should do with it... Let's see, what can you do without causing horrible environmental damage? Hmm... You could:
Which option pollutes less? Guess what? They're all basically equivalent! There's no environment to pollute!
Yes, it really is that simple. Strip mine the moon and build factories on it until it's nothing but a giant cesspool of industrial waste - WHO CARES?! It's the moon! There's nothing there!
You can compile Java directly to machine code which runs without an interpreter too. Compiled vs. Interpreted is not the same as how high level the language is.
And actually, it doesn't compile "directly" to machine code. It's compiled into some sort of compiler-specific intermediate form where it gets optimized, and then output as machine-specific assembly. The assembler is the tool which creates machine code.
It's quite possible to compile almost any interpreted language to a machine executable, if you really want to. Some may be quite inefficient, of course. It's also possible to run any language in an interpreter.
The distinction between a high level and a low level language is very fuzzy, and roughly refers to the level of abstraction it provides for abstract data types, objects, memory management, etc.
C is a "mid-level" language, because it doesn't provide native support for objects, lists, trees, garbage collection, etc. However, it can certainly support all of these with the proper libraries (except garbage collection, which is more difficult - you need some compiler support too generally, but it's possible).
Java, on the other hand, is considered somewhat higher-level, because it provides native object and garbage collection support, and standard library support for many data types. It also attempts to place stronger guarantees on the consistency of the runtime state.
Other languages, such as python or perl, might be considered higher level still, with intrinsic list and associative array support, etc. So could lisp.
But then, the whole high/low level thing is extremely fuzzy. For instance, lisp supports garbage collection, arrays, etc., as well as closures, lambda functions, runtime code generation, etc., all very high level. But it doesn't natively support objects. So, an OOP person might laugh at it with disdain, especially since it's basically the oldest language still in use.
C++ also supports a medly of "high level" features (some relatively unique), but lacks garbage collection and the sort of strong internal consistency guarantees interpreted languages provide, so some people scoff at its high-level-ness as well. And of course, you can fiddle with memory locations directly if you want and play with inline assembly as well.
In terms of this sort of discussion, the relevant comparison was about the wordiness of the respective languages. But of course, this is also a completely deceptive comparison, since you have to ensure they're doing precisely the same thing. If you select a task where one of them comes with a library that does exactly that, and the other one doesn't, you can easily make any language look far more concise than any other.
For instance, say I make a language, asm-foo, which is assembly except, I include the function, foo, which takes no arguments. foo will automatically run a GUI based office suite on the current display which allows the user to perform a number of tasks. :-)
Here is my office suite software, in hand-optimized intel x86 asm-foo assembly code:
main:
call foo
ret
Please show me another language besides asm-foo where I can write an office suite more easily. :-)
Oops, bourne shell script?
#!/bin/shexec openoffice
Doh!
Heh.
You do realize, every single thing you've stated is already done by linux, automatically, only about a million times better than the way you propose doing it, right?
Oh, you mean, like, say, maybe, er, um, say, a shared library? Oh, wait, what's that? You mean, Linux has those? And in fact, it even supports versioning of them, so if you have two applications which require incompatible versions of the same library, they can still work too, unlike Windows? I'm shocked! Shocked I say!
This is a ridiculous idea. Wouldn't it be better to just have a program which keeps track of which libraries a program needs, and not remove them if they're needed by something? A program which manages all the application files on your system, and handles interdependencies and conflicts automatically? Maybe we could bundle the files together into, oh, I dunno, packages, and call this a Package Manager. Wait, that's an amazing idea! I should patent it!
Wait, I have an even more shocking idea. What if, say, I wanted to upgrade a library that's in use by a program that's running right now. Wouldn't it be great if I could atomically drop the new library over the old one, and let any programs that are still using the old one keep using it until the last program using it exits, at which point the library is automatically deleted by the OS? Wouldn't that be a shockingly cool idea? New programs would get the new library, old ones would still have the original to use until they shut down! That way, I could upgrade live, running software and have it actually work! I should patent that too!
Oh wait, what's that, what's that you say? Linux does all this, already, automatically, and in fact, has done it for years and years? I'm shocked! Shocked I say!
You entered: noses
Possible responses: nose
Result: FAIL.
Wohoo! I'm a robot! This test proves it! Vegas here I come!
Why does this test make me feel like I just had a run-in with John Ashcroft?
Nothing would stop some idiot from making a binary patch to your app *cough* crackers do this today to every app *cough* and distributing it wildly, and then have everyone calling your tech support for help. Your point?
Ever heard of a Xerox machine? A scanner? Having the source or not having the source has absolutely no effect of any kind or form whatsoever on the meaning of copyright.
And you're right, software is easy to copy. Exactly how is software in binary form harder to copy than in source form, again?
I see you've never taken a CSE class at a university. Software exists which will take two code bases, possibly with completely different names and formatting, and decompose them into structural parse trees and compare those for signs of copying.
It's a lot easier to do this if you have the source code, of course.
The reason it'll be more difficult is because more state is being held on the server side, which will have to be pushed back to the clients (which were supposed to be super-simple) and then restored to the new server somehow. Building it into the protocol is of course possible, but that will inherently break the simplicity requirements of the design.
Consider. Say I have an application that opens an edit widget, and the user types in part of a document, with particular formatting, etc. Under the "very high level" approach, the server will just pop up an edit widget here and everything will happen on the server side. At particular points, the server will synchronize with the client, say when the user hits a special button which does something useful. Many parts of the display need never be sent back to the client under this approach, such as the entirety of the internal state of the widget - that was the point of the design, after all, in that internal drawing state of the widgets doesn't go over the wire.
Now, consider this with the arbitrary disconnect requirement. The wire may be cut at any time, and the client side app is expected to have enough data to rebuild its UI on a new server in exactly the same way. This is an inherent limitation, because it means that all of the internal state changes of every server widget needs to be transmitted back to the client immediately, and in addition, all the server-side widgets have to be stateless (they have to support reconstruction at any point). Suddenly, your protocol is a whole lot more chatty.
This also means that the clients are much more complex. They can't be elegantly simple any more, because they have to replicate the entire widget state from the server at all times. You effectively end up with both ends running a copy of the widget set, which of course, means that you can't dramatically re-theme them on the server, because that requires a protocol change. Ouch!
The alternative, of course, is to do it like X11, and run a special proxy server on the client side, which stores all the state locally and knows how to talk to a remote server to reconstruct it. This will be quite involved, especially if the protocol doesn't support completely stateless widgets - it might have to run through some virtual user operations on a widget just to restore its state. This looks like xmove, of course, only even more complex.
Of course, if you do that, why even bother? You could get the same benefits (if any) by just making a protocol extension to X11 for GTK, which is only implemented inside of xmove. GTK apps would detect a special X server, describe their GUI using the new method, and then the special server and special clients could communicate through a special, higher level protocol. Non-gtk apps could go through standard X calls, or a bitmap scheme like vnc.
The migration difficulty in developing a new version of the X11 protocol (X11R7?) and updating all the apps to not use the deprecated features would be far less than developing a new system from scratch. If done carefully, deprecated features would be available through a module during the migration period. At the same time, new features which are available through extensions would simply be merged back as part of the main protocol. This sort of thing takes a while, but it could be done and would be far less painful.
Of course, whether it's worth doing is another matter. Probably not, because X works fine for now. But it's a more viable course to take than replacing X from scratch.
I run X11 programs over the internet all the time. It works fine, and is perfectly usable. Just use ssh -C -X, and it compresses the protocol stream. Or, you can use one of the protocol compressors. This is even somewhat usable over a modem, though I don't use those any more.
Ironically enough, there is a remote connection system that's even faster and snappier, though: TightVNC. With 8-bit mode and compression, it's completely usable and has almost no discernible latency over my cable modem line. Why is this ironic, you ask? It's ironic because it's exactly the opposite of your point: It's even *lower level* than X11, since it takes bitmap snapshots of the display and sends those! X11 at least has the good sense to send high level drawing primitives like rectangles!
What this goes to show is, one size does not fit all. One solution is not best in all situations.
Another useful example of this principle is when you consider moving applications between displays (or detaching them completely). This is a very nice thing to do, and is very easy with VNC, since no state is stored in the client. It's much less easy to do in X11, since you end up needing to use a quite complex protocol adaptor which actually is a whole server in itself to accomplish the same thing (since it has to remember all the state). In an even higher level system like picogui, this will be even harder still.
X11 is a good system and works fine. There just isn't a compelling reason to dump it. A much better idea might be to invest in some cleanup efforts in X11 itself. For instance, the protocol is rather old and is becoming somewhat more crufty with time. Perhaps it can be improved and cleaned up with some careful thinking.
On the other hand, the central point that was completely missed (as usual) in this /. discussion is that this doesn't mean picogui is bad. One size does not fit all - meaning, X11 may actually not be the best solution on your palm pilot!
For the WineX supported games (eg. WCIII, The Sims) the performance will be reduced significantly, but it'll generally still be ok. This is still being worked on - there will probably always be a small amount of overhead if the game uses Direct3d, but other than that, there's no inherent technical reason that it should be slower under Linux (so consider this a bug).
For native games, such (eg. NWN (we hope), and UT2k3) the performance is pretty much identical if you're using an NVidia card. Well, identical or a little faster than windows, usually. The NVidia drivers are basically the same for Linux and Windows, but at least some games (eg. Quake3) have benched a bit faster under Linux.
Warcraft III works fine on Linux.
Go to www.transgaming.com
Linux supports HT. No OS as far as I know sees much benefit from it.
The difference between a "process" and a "thread" is pretty small. A thread is just a process with shared page tables, for the most part. This means that there's less overhead switching between two threads, since you don't have to flush the TLB and caches. The processor per se knows absolutely nothing about any of this - it just knows when the OS commands it to flush the TLB and the caches, and change the page table addresses.
The basic point of HT is that it's sort-of another CPU, but it's just leeching unused resources from the main CPU. So, the scheduling logic in the OS needs to understand that it's not a real CPU, and thus should be grouped with the real CPU it's associated with. Linux 2.5/2.6 will support these tweaks, with 2.4 you'll need some sort of patch currently. Without the tweaks, you still get HT, it just doesn't help much.
But really, it never helps that much. Don't expect a 2x speedup or anything, even if your system is running heavily threaded applications.
To be more specific, you can't go beyond 2-3GB per process using intel, at least, directly. (You could access more indirectly, just not as actual memory.)
The reason is that the kernel needs memory too. Say you try to load some data from disk. You call the read() system call, which switches to the kernel execution context. The kernel then checks to see if the data you're trying to read is available in the disk cache. If it is, it copies. If it's not, it schedules a load, puts your process to sleep, and when the load finishes, it copies.
So, basically, either way, the kernel needs to be copying data from the disk cache to your program's memory space. This means, it needs to see both at once!
The standard way this works is, all physical memory (which might be used as cache) is mapped into the kernel, normally limited to the high 1GB. The user process gets the low 1GB. So, when you switch to kernel mode, the kernel has all memory, physical and program-virtual, available to it.
Now, some people have more than 1GB ram. The easiest thing for these people to do is use a 2/2 split, if they only have 2GB. This means the process can't use more than 2GB at once, but usually that's ok because most programs don't need that, really. A 1/3 split is also possible.
However, obviously no straight split scheme like this is going to work if you install 4GB of ram! Instead, the kernel is going to have to play some trickery with the page tables and segment registers to get access to this extra memory. This way, it can support more than 1GB, up to 64. The user process of course is still limited to 3.
The problem here, of course, is that doing tricks to get access to your memory in the kernel is obviously going to be slow. So, a kernel that actually tries to use more than about 1 (or maybe 2) GB of ram will be slower than a kernel which does not, and this is unavoidable. Now, this may be just fine, because that extra ram can be used for disk cache - and if your program uses a stupendous amount of disk space, even if the kernel is slower, the huge disk cache will still be a big help for you.
But to make a long story short, >1 (or at most, 2) GB of ram will actually make your computer slower, unless you actually do something which uses all of that ram.
None of this would be true, of course, on a 64-bit machine.
Look at them under a magnifier. The first screenshot (the before) has antialiasing turned on. You can also tell this by looking at the 2 at the bottom. It's been antialiased into complete garbage, and is missing an entire stroke.
The second screenshot (after) has antialiasing turned off. This means that the spacing is a little less well-hinted, but on the other hand, you can at least see the strokes, and it doesn't look that blurry.
Of course it's your duty to disobey some laws.
One obvious, and unarguable example of this, is when a law is not a law.
For instance, when congress passes a law stating that it's illegal to publish an article in a newspaper, that law is not a law in the USA. It's just some meaningless verbiage they spewed out on paper to show their own incompetence. Why? Because the constitution says they can't do that.
Now, the cops can arrest you for that, but in doing so, they're themselves violating the law by performing a false arrest. (It so happens that they can't be punished for it, but in effect, they are). Now, obviously, if everyone cowered in fear from the big mean police and never attempted to utilize their rights, it would be as if those rights didn't exist. So clearly, you have the duty to disobey, or at least (if the issue is irrelevant to you) simply ignore an illegal law.
Now, as for a simply unjust law, things aren't quite so obvious since it's certainly possible that a law is legal, but simply absurd. But then, you have to consider that laws are made by people, and can say anything at all. There are no inherent checks on them - so clearly, not all laws should be, or can be, obeyed. For instance, a law ordering you to rob your neighbors and give their property to your local police department is one you have a duty to disobey, even if it wasn't obviously illegal. Er, oh wait, that's basically what the RICO laws state, and the supreme court found them to be within the law. I guess that law actually is legal. Should you obey it?
Writing a PPC emulator is not a big deal. Emulating any processor ISA on any other is not a big deal. You can write one in C that's fully cross platform and works anywhere, even.
Emulating the whole system so it can run full OS software is much harder, since you have to emulate a lot more than just the CPU. There's nothing special about macs here - in fact, it would be easier since they're rather standardized - it's just more to do.
The problem with emulation isn't that it's hard. It's not. It's that it's slow. Writing a fast emulator for a PPC chip on an x86 would be quite difficult. Of course, this goes for any other chip, not just the PPC, as well. The x86 chips are actually harder to emulate, because they're so bizarre and badly designed, in truth.
The reason PPC Mac emulators are hard to find is because nobody wants one. There a strong demand for emulators to run software that won't run otherwise. There's very little Mac software in that category, so hardly anyone wants an emulator for them. At least, they don't want one bad enough to write it.
It is true that oil is dirty. However, it's also true that we're not going to run out.
The alternatives the previous poster mentioned are already being worked on.
Basically, what's going to happen is that as oil reserves are depleted, the price will increase. Eventually, it will rise above the price of alternative sources of oil.
What are these alternative sources? Well, for starters, it's possible to refine oil from coal. This process is more expensive than just pumping it out of the ground, so we don't do it right now. When the price of oil rises enough, it will make more sense to use coal.
There's a lot of coal in the world.
When the coal runs down, after a few thousand years, the price will again start to rise a bit, at which point a second alternative will be attractive, if it isn't already: oil shale.
When the oil shale runs out, after many more millennia, we'll either find a new energy-rich source, or we'll go full synthetic. Of course, full synthetic production will run at an energy loss, so it will need a real power source such as solar or nuclear power to drive it.
Synthetic oil production will be viable for more or less the lifetime of the universe.
One example of a form of "synthetic" oil production here is refined vegetable oil, by the way. Solar powered crops can be replanted every year, and thus won't run out.
Of course, actual oil from the ground won't run out either. It's just that new reserves won't form at nearly the rate we like to use it, so it'll always be insufficient to fill demand after the current fields are depleted.
So, no, we'll never "run out" of oil.
We will, on the other hand, want to stop using it because it's dirty long before we reach synthetic production. When we actually do stop using it, who can say?