I set DisplaySize to 338 270. The math came out to 337.92 so I figured that was more correct. Refresh is 75hz. But I given up and gone back to no subpixel and some hinting and its readable. It shouldn't ever take more than 30 seconds to turn on subpixel rendering on any system and have the fonts look better than without it.
I am also using Gentoo ~x86 with nvidia. All the same software versions. I followed the gentoo manual just like you probably did. I set up fonts/local.conf just like you wrote. I tried your DisplaySize and it was fuzzy, so I calculated the proper DisplaySize for my monitor, a Dell 1703FP, and it is still fuzzy.
I tried your fonts and they are large enough that it's difficult to see the blur. But that's not a solution to the problem because I don't particularly want to use large fonts. I don't have to in order to make Windows viewable when I use it. I have tried the most recent Mandrake and SuSE, neither of which set the DisplaySize variable btw and they both have fuzzy fonts, along with Red Hat 9 and Fedora Core 2.
Some fonts and sizes look okay; maybe I should set all the fonts on my system to the same size? I know it is not a hardware problem because dual-boot Windows is clear as day.
To sum up the posts:
* it must be your fault because you are using a "strange" distro... like SuSE, Fedora or Mandrake.
* it's easy, just edit this xml file... oh wait you also have to set this magic value exactly right in another text file.
* it works for me, so you must just suck
So what's next sherlock, use a hex editor? recompile the kernel? The fact that the fonts are clear on Windows after doing nothing and crap on Linux on my system even on major distros and hours of work tells me something is wrong with fonts on X. Maybe some systems have smooth fonts in X. Maybe most do. I wish mine was one of those.
So post your system specs then... I want to see good fonts on Linux, and the other poster sounds like they would try a different distro if the fonts would work on it.
Re:Concentrate on decent font supp -- mod parent u
on
Xorg and Desktop Eyecandy
·
· Score: 0, Offtopic
Me: Here's a hint: when people say they've tried damn near everything
JustSomeGuy: No you didn't. You said that you tried a few things but completely left out how you tried to go about them.
Original post: I have wasted hour after hour following various FAQs, playing with antialiasing, autohinting, and subpixel rendering in my ~/.fonts.conf. I have installed the Bitstream Vera fonts. I have sacrificed a goat and done a rain dance. And still, all those fonts look so blurry that I feel like I'm going blind.
What, you think people have gone to all those lengths but nobody thought to try the freakin' subpixel rendering button in preferences? This is/. not aol.
Read the context for christ sake! When I say "yes, I agree, I have also done those things" and you say "but you just said 'those things' not what they were" without reading the post I was replying to, that makes you a 'tard. One with +4 moderation, but still a tard.
Re:Concentrate on decent font supp -- mod parent u
on
Xorg and Desktop Eyecandy
·
· Score: -1, Flamebait
In other words, it sounds like you have problems with the way your desktop of choice is configured for AA fonts. Understand that other desktops handle the job quite gracefully and with good results.
Yeah I broke 95 percentile on topcoder but somehow it's my fault that antialiased fonts can be a real bitch in X. Here's a hint: when people say they've tried damn near everything and list most of them and you come back with trivial crap like "select fonts->use antialiasing then "use sub-pixel rendering" when that's exactly what the complaint was, that doing that makes the fonts blurry you just sound dumb.
There are problems with X.org and antialiased fonts. Not every combination of monitor and config has it bad, and some users don't even notice because they have bad vision or nothing to compare to. But when the solution is to edit some XML config file that "it" told you to, and that doesn't even solve the problem, then something needs fixing big time. Do a screenshot of the same page in Win32 Firefox and X11 Firefox sometime and you'll see what I mean.
Just implement the X windowing system on top of an OpenGL renderer. It's easy. Hell one guy in his spare time did it for the Looking Glass desktop and it looks and works a heck of a lot better than any other X eye candy. It's java + opengl + x11 interpreter, but if it's just Java that is the holdup then use freakin' python or mono; it doesn't have to be fast just to manage window bounding regions and script opengl native code.
Is the new 'modular' X server actually going to be written in C/C++? WTF for? The clear leader, Apple, uses a subset of PDF and the OSS guys' new achitecture is more structs of function pointers?
You should be modded up for that comment. Fonts on LCD do suck on X. I have also tried different subpixel renderings, all the rgb alignments, etc on digital and analog flatpanels with no luck.
The only real solution for me had been to turn off subpixel rendering entirely and use fonts from Windows. Best I've been able to find so far is Tahoma 12/10, and Courier New for terminal window; it's tolerable although fairly jaggy with no aliasing. But blurry is much worse.
Suppose for example grokster distributes a filesharing product and advertises one time that it can be used to copy music. My question is, what is the crime?
I suppose it is inducement to commit copyright infrigement, but the case says they are liable for what their users do with the software so that can't be it since they would be liable regardless of whether users were actually induced or not. So they must be liable as an accessory before the fact for each instance of users violating copyright with the software.
The problem I have with this decision is that for one action grokster is apparently committing new crimes (civil or criminal) without doing anything more. This could go on basically forever. In my mind it's roughly equivalent to some Joe Worker tripping and hitting a switch at some refinery that causes an explosion killing 1000 people. Under the current system he can be tried 1000 times, each time arguing that he did it intentionally. Seems like a violation of double jeopardy to me, that the DA can roll the dice over and over until some retarded jury finally convicts the guy or he loses 1000 times. That's how it is, but it doesn't seem right. To me it's mostly the same issue: one act but can be tried any number of times.
The company should really be found guilty of creating or distributing a filesharing product, but these things are not illegal afaik.
Who says having a brain means you have to use it? Nobody? You're okay then.
They don't say they are going to add f'ed up metadata to wikipedia? Can't happen then. They didn't say it.
They didn't say my wikipedia experience will change? Can't change then. They didn't say it would change, so it won't.
Never mind what I do, only what I say. Don't be concerned over the results, only the intentions. That's kind of a f'ed up mentality. Now give me my -1 for responding to flamebait.
Wikipedia is an encyclopedia, not a freaking "big bag of web-accessible content". Wiktionary is a freaking dictionary not a 'big bag of langauage factoids'. Etc. Adding a page on some band and having the music player display it is fine, but is sounds like KDE is figuring on putting their freakin' user manuals on wikipedia and adding geeky meta-data to pages. That's just crap.
It wouldn't bother me except the KDE people seem to suffer from Microsoft's disease, aka a near-total lack of good taste; it's not like KDE isn't 10x more featureful and capable than gnome, it's that it's just gross... it looks like it was designed by multiple geekoids battling each other for maximum dweebiness. Or something like that. I just don't want them to do that to wikipedia, which is cool as hell as-is.
c) "Many cases slower than Java" is the sort of unsupportable bullshit that people make when they're trolling. Yes, message passing is slower than virtual function calls (and Javas are [much,much] slower than C++s vcalls).
What is that, fight FUD with FUD? Typically in languages like Java a virtual method is first emitted as calling a handler instead of the actual method, which goes back and re-writes the call site with a C++-style virtual dispatch table. So really only the first invocation with a given type is slower, and also after loading a new class where affected tables are cleared and constructed again at the next call. This trick is also how languages like Smalltalk and Python can acheive respectable performance despite being completely dynamic.
Microbenchmarks will say the C++ virtual method is faster since in these small codes the compiler often will inline several possibilities as branches instead of jumps, so you are not really comparing virtual method performance at all but rather the optimization of eliminating the call entirely. And on this optimization Java typically kicks the crap out of C++ in real programs. For example, if you have calls A->B->C->D->E with a huge for loop at A, Java will optimize the whole thing as one huge block and eliminate 4 method calls per iteration. Getting C++ to do this is very difficult... you usually have to *know* this is the chain of calls to inline and, if the calls are used elsewhere, make separate copies that are inline / not inline or the application size will explode.
Ultimately Java is slower than C++ for two major reasons: mandatory array bounds checks and mandatory garbage collection (where C++ can allocate a million homogeneous objects in one malloc it takes a million new's in Java). Java can also be slower at some really tight codes (like codecs) because it does fewer really costly optimizations and doesn't allow embedded assembly statements. But for virtual call performance and new/delete on heap it simply destroys C++ wrt performance.
and GC has little to nothing to do with the relative security of C and Java (theres some obscure security flaws related to misuse of buggy versions of malloc(), on the other hand there's obscure flaws related to abusing the GC scheme to bypass Javas typesafety.
Uhh, no and no. The Java flaws have been in the bytecode verifier, which has nothing to do with the GC, and in the class loader which allowed access to classes that it shouldn't have (applets allowed to use packate-private classes). All of the known Java security flaws have been fixed, whereas malloc flaws remain because they are a side effect of the functioning of malloc. So you get a buffer overflow or uninitiated pointer in C++, Objective C, or C and you are potentially very screwed. These are impossible in Java, so yes, it is much safer by design. The reality is that most Objective C programs will be relatively safe. C++, C? Not so much, it really depends more on the skill and hard work that went into them to prevent security holes.
I suppose you could make many BSD drivers work under the x86 Darwin with little tweaking, but I might be wrong.
Mac OS X has a completely different, subset of C++ driver system called IOKit. They did this because the *BSDs had basically no ability to change power states, and writing new drivers was time consuming (now you subclass a similar driver that does not of the work already).
So, no, it would take a complete re-write to get normal BSD or Linux drivers into OS X.
And it happens plenty on "traditional" supercomputers. That's why you stick a fast interconnect on them, like myrinet or infiniband and don't use just ethernet
It happens on traditionaly supercomputers, but it's crappy and slow. I point you to this paper. Why double the code and memory to get much worse performance? Because 'throw 1000 pentiums in a room' is already there to solve the easily parallel problems. That they are already there is the only reason to use them for solving a dynamic problem.
These ranking are based on LINPACK doing traditional operations like solving linear equations, so supercomputers like the Cray MTA aren't even listed even though for some grand challenges they destroy everything else, for example when doing dynamic mesh weather simluations. Each processor on the memory grid has 128 processor threads where the active thread switches every cycle (so memory fetch has huge latency). This lets it have a unified memory model and still have extremely high throughput.
So the MTA can adjust the mesh to compute the tornado in very fine detail while using far fewer points for the huge swaths of calmer weather around it. Traditional supercomputers can't do that well since just distributing the data points to each processor is so much overhead.
If anything, there was something far more insidious going on elsewhere and this was an attempt to divert the all powerful Slashdot crowd's attention to something worthless.
You mean like installing a traffic camera on Sesame Street to catch the liberal bias? Or the new Big Bird Sandwich at Hardee's?
Only like 5% max of the people should be republican; the rest are uneducated, uninformed, or bigots. That's why eliminating mass education will always trump non-skippable commercials in tivo.
Yes, if instead of 'plain' blocks you get combinations such as "A xor B" then knowing A you can get B and vice versa. So you can re-create hard to find blocks from easy to find ones.
What they don't mention is that it may improve the network bandwidth, but it trades it for much more work on the client. You can't just write A^D to it's final location in the file until you know A or D, so this has to be stored someplace. And during normal operation instead of just reading the block the other peer requested and sending it, the software has to read two or more blocks to combine them (block to combine with could be a recently received one, but still).
So in the end it doesn't reduce the amount of information send/received since ultimately each client has to receive the whole file (see information theory). So you are guarenteed at least several times more disk access and a lot more memory usage for your download, but it may finish sooner if the torrent can't provide some blocks quickly, which only seems to be the case really with a low-bandwidth tracker.
It's just like in Asimov's robots and empire books where people become more and more isolated, to the point where they don't even want to communicate with their neighbors through holographms because even an image is too icky and uncomfortable.
People don't talk to their neighbors, now they won't go to a movie because other people are making them uncomfortable basically just by being there. I guess the next step would be restaurants that have rooms instead of tables. Maybe a virtual church pew or virtual t-ball?
The truth is that they usually copy other research, tweak it up a bit (usually making it worse), and pretend that they invented it in the first place. Typical Microsoft... it must be something in the water up there.
In this case, the original is Tapestry, published at latest Apr 2001, followed by Pastry (hence the name) which was "done in part while visiting Microsoft Research, Cambridge, UK". Sounds to me like the main "innovative" part was providing a few computers. Meanwhile, the really new ideas (ala Chord) come from other places.
What would be better would be some form of patent jury. Select 12 people from the jury pool and treat the patent application kinda like a trial. If the applicant can convince 12 laymen, beyond a reasonable doubt, that the patent is non-obvious and innovative then they grant the application.
Then you get some retarded 'one-click' patent and there better be a halluva case put on for it or the jury will just laugh at it. It would automatically make the application have to be clear, because what jury is going to find for a patent they can't understand? Normal people get irritated by fancy language and take it out on whoever is doing it. You might get some advanced science patents rejected because the applicant can't teach normal people enough to understand whether it is a novel idea or not, but if you can't learn some normal person enough to tell how is a government worker going to be any better?
This is kinda a joke idea, but it gets to the heart of what's really missing from the process: the judgement call. Patent reviewers should be able to reject an application because the wording is too complicated, or because they just feel it is obvious, or even just not in the public interest -- not just yes/no based on existence of easy-to-find prior art. Give the same application randomly to several reviewers and use that to weed out the bad clerks (the ones that always deny no matter what, etc).
Doing either of the above might seem like a lot more cost, but I doubt it. When companies can no longer patent anything by making the application artificially complex or for something obvious there will be a LOT fewer application. Plus it will be worth any cost just to get readable patents.
With an OS written in a safe language, for safe languages, everything runs in ring 0. You don't have to use page tables; you can if you want to, with no requirement for any more assembly than otherwise.
There are plenty of people who could use a 'free' extra computer for browsing the web. It's like back when kids had to share the phone -- even one line per kid wasn't enough. So now instead of having to share whatever computers you have (maybe none) or buying a $300 wal-mart computer just to get the rugrats out of your hair they can just use the PS3 to do it; it's got an ethernet connection anyway to play on-line games.
It's not like setting up Linux for PPC to boot to a blank screen with a web browser requires much investment. And you get the geek vote, can sell a few more peripherals, and make the parents happy. What's not to like about it?
They should ship it with a knoppix-like distro on DVD. With that much space they could put basically everything in the known, open-source universe on it. Could even use the memory cards for some small amounts of data.
And the reason why
for (x=0; x < 10000000; x++)
getpid();
takes 1 second due to system call overhead instead of 0.001 seconds is because C is such a great language for operating systems... hint: it's one instruction in a "safe" OS (ie not C/C++).
Parent:
Java and C# are slow because Python is slow
And that's suppose to be insightful? Python is slow. Java and C# are not. The only reason these languages show up lower in benchmarks are array access checks and, for Java, no stack-based variables.
Basically the question of keyboard vs mouse comes down to analog vs. digital. We use a keyboard to type characters because, for a computer, they are digital; there's no ascii code for "C that's looks kinda like a G". We use a mouse to do graphic art because a brush stroke is not a simple line. We use the keyboard to go forward and strafe in a FPS because it's either full-on or not, but a mouse for aiming since rate of rotation is continuously variable.
Slashdot Mirror
I set DisplaySize to 338 270. The math came out to 337.92 so I figured that was more correct. Refresh is 75hz. But I given up and gone back to no subpixel and some hinting and its readable. It shouldn't ever take more than 30 seconds to turn on subpixel rendering on any system and have the fonts look better than without it.
I am also using Gentoo ~x86 with nvidia. All the same software versions. I followed the gentoo manual just like you probably did. I set up fonts/local.conf just like you wrote. I tried your DisplaySize and it was fuzzy, so I calculated the proper DisplaySize for my monitor, a Dell 1703FP, and it is still fuzzy.
I tried your fonts and they are large enough that it's difficult to see the blur. But that's not a solution to the problem because I don't particularly want to use large fonts. I don't have to in order to make Windows viewable when I use it. I have tried the most recent Mandrake and SuSE, neither of which set the DisplaySize variable btw and they both have fuzzy fonts, along with Red Hat 9 and Fedora Core 2.
Some fonts and sizes look okay; maybe I should set all the fonts on my system to the same size? I know it is not a hardware problem because dual-boot Windows is clear as day.
To sum up the posts:
* it must be your fault because you are using a "strange" distro... like SuSE, Fedora or Mandrake.
* it's easy, just edit this xml file... oh wait you also have to set this magic value exactly right in another text file.
* it works for me, so you must just suck
So what's next sherlock, use a hex editor? recompile the kernel? The fact that the fonts are clear on Windows after doing nothing and crap on Linux on my system even on major distros and hours of work tells me something is wrong with fonts on X. Maybe some systems have smooth fonts in X. Maybe most do. I wish mine was one of those.
So post your system specs then... I want to see good fonts on Linux, and the other poster sounds like they would try a different distro if the fonts would work on it.
Distro: ?
KDE version: ?
X.11 verson: ?
Font: ?, Size: ?
Monitor: ?
Graphics card: ?
Me: Here's a hint: when people say they've tried damn near everything
/. not aol.
JustSomeGuy: No you didn't. You said that you tried a few things but completely left out how you tried to go about them.
Original post: I have wasted hour after hour following various FAQs, playing with antialiasing, autohinting, and subpixel rendering in my ~/.fonts.conf. I have installed the Bitstream Vera fonts. I have sacrificed a goat and done a rain dance. And still, all those fonts look so blurry that I feel like I'm going blind.
What, you think people have gone to all those lengths but nobody thought to try the freakin' subpixel rendering button in preferences? This is
Read the context for christ sake! When I say "yes, I agree, I have also done those things" and you say "but you just said 'those things' not what they were" without reading the post I was replying to, that makes you a 'tard. One with +4 moderation, but still a tard.
In other words, it sounds like you have problems with the way your desktop of choice is configured for AA fonts. Understand that other desktops handle the job quite gracefully and with good results.
Yeah I broke 95 percentile on topcoder but somehow it's my fault that antialiased fonts can be a real bitch in X. Here's a hint: when people say they've tried damn near everything and list most of them and you come back with trivial crap like "select fonts->use antialiasing then "use sub-pixel rendering" when that's exactly what the complaint was, that doing that makes the fonts blurry you just sound dumb.
There are problems with X.org and antialiased fonts. Not every combination of monitor and config has it bad, and some users don't even notice because they have bad vision or nothing to compare to. But when the solution is to edit some XML config file that "it" told you to, and that doesn't even solve the problem, then something needs fixing big time. Do a screenshot of the same page in Win32 Firefox and X11 Firefox sometime and you'll see what I mean.
Just implement the X windowing system on top of an OpenGL renderer. It's easy. Hell one guy in his spare time did it for the Looking Glass desktop and it looks and works a heck of a lot better than any other X eye candy. It's java + opengl + x11 interpreter, but if it's just Java that is the holdup then use freakin' python or mono; it doesn't have to be fast just to manage window bounding regions and script opengl native code.
Is the new 'modular' X server actually going to be written in C/C++? WTF for? The clear leader, Apple, uses a subset of PDF and the OSS guys' new achitecture is more structs of function pointers?
Snap out of it, red.
You should be modded up for that comment. Fonts on LCD do suck on X. I have also tried different subpixel renderings, all the rgb alignments, etc on digital and analog flatpanels with no luck.
The only real solution for me had been to turn off subpixel rendering entirely and use fonts from Windows. Best I've been able to find so far is Tahoma 12/10, and Courier New for terminal window; it's tolerable although fairly jaggy with no aliasing. But blurry is much worse.
Suppose for example grokster distributes a filesharing product and advertises one time that it can be used to copy music. My question is, what is the crime?
I suppose it is inducement to commit copyright infrigement, but the case says they are liable for what their users do with the software so that can't be it since they would be liable regardless of whether users were actually induced or not. So they must be liable as an accessory before the fact for each instance of users violating copyright with the software.
The problem I have with this decision is that for one action grokster is apparently committing new crimes (civil or criminal) without doing anything more. This could go on basically forever. In my mind it's roughly equivalent to some Joe Worker tripping and hitting a switch at some refinery that causes an explosion killing 1000 people. Under the current system he can be tried 1000 times, each time arguing that he did it intentionally. Seems like a violation of double jeopardy to me, that the DA can roll the dice over and over until some retarded jury finally convicts the guy or he loses 1000 times. That's how it is, but it doesn't seem right. To me it's mostly the same issue: one act but can be tried any number of times.
The company should really be found guilty of creating or distributing a filesharing product, but these things are not illegal afaik.
Who says having a brain means you have to use it? Nobody? You're okay then.
They don't say they are going to add f'ed up metadata to wikipedia? Can't happen then. They didn't say it.
They didn't say my wikipedia experience will change? Can't change then. They didn't say it would change, so it won't.
Never mind what I do, only what I say. Don't be concerned over the results, only the intentions. That's kind of a f'ed up mentality. Now give me my -1 for responding to flamebait.
Wikipedia is an encyclopedia, not a freaking "big bag of web-accessible content". Wiktionary is a freaking dictionary not a 'big bag of langauage factoids'. Etc. Adding a page on some band and having the music player display it is fine, but is sounds like KDE is figuring on putting their freakin' user manuals on wikipedia and adding geeky meta-data to pages. That's just crap.
It wouldn't bother me except the KDE people seem to suffer from Microsoft's disease, aka a near-total lack of good taste; it's not like KDE isn't 10x more featureful and capable than gnome, it's that it's just gross... it looks like it was designed by multiple geekoids battling each other for maximum dweebiness. Or something like that. I just don't want them to do that to wikipedia, which is cool as hell as-is.
c) "Many cases slower than Java" is the sort of unsupportable bullshit that people make when they're trolling. Yes, message passing is slower than virtual function calls (and Javas are [much,much] slower than C++s vcalls).
What is that, fight FUD with FUD? Typically in languages like Java a virtual method is first emitted as calling a handler instead of the actual method, which goes back and re-writes the call site with a C++-style virtual dispatch table. So really only the first invocation with a given type is slower, and also after loading a new class where affected tables are cleared and constructed again at the next call. This trick is also how languages like Smalltalk and Python can acheive respectable performance despite being completely dynamic.
Microbenchmarks will say the C++ virtual method is faster since in these small codes the compiler often will inline several possibilities as branches instead of jumps, so you are not really comparing virtual method performance at all but rather the optimization of eliminating the call entirely. And on this optimization Java typically kicks the crap out of C++ in real programs. For example, if you have calls A->B->C->D->E with a huge for loop at A, Java will optimize the whole thing as one huge block and eliminate 4 method calls per iteration. Getting C++ to do this is very difficult... you usually have to *know* this is the chain of calls to inline and, if the calls are used elsewhere, make separate copies that are inline / not inline or the application size will explode.
Ultimately Java is slower than C++ for two major reasons: mandatory array bounds checks and mandatory garbage collection (where C++ can allocate a million homogeneous objects in one malloc it takes a million new's in Java). Java can also be slower at some really tight codes (like codecs) because it does fewer really costly optimizations and doesn't allow embedded assembly statements. But for virtual call performance and new/delete on heap it simply destroys C++ wrt performance.
and GC has little to nothing to do with the relative security of C and Java (theres some obscure security flaws related to misuse of buggy versions of malloc(), on the other hand there's obscure flaws related to abusing the GC scheme to bypass Javas typesafety.
Uhh, no and no. The Java flaws have been in the bytecode verifier, which has nothing to do with the GC, and in the class loader which allowed access to classes that it shouldn't have (applets allowed to use packate-private classes). All of the known Java security flaws have been fixed, whereas malloc flaws remain because they are a side effect of the functioning of malloc. So you get a buffer overflow or uninitiated pointer in C++, Objective C, or C and you are potentially very screwed. These are impossible in Java, so yes, it is much safer by design. The reality is that most Objective C programs will be relatively safe. C++, C? Not so much, it really depends more on the skill and hard work that went into them to prevent security holes.
I suppose you could make many BSD drivers work under the x86 Darwin with little tweaking, but I might be wrong.
Mac OS X has a completely different, subset of C++ driver system called IOKit. They did this because the *BSDs had basically no ability to change power states, and writing new drivers was time consuming (now you subclass a similar driver that does not of the work already).
So, no, it would take a complete re-write to get normal BSD or Linux drivers into OS X.
And it happens plenty on "traditional" supercomputers. That's why you stick a fast interconnect on them, like myrinet or infiniband and don't use just ethernet
It happens on traditionaly supercomputers, but it's crappy and slow. I point you to this paper. Why double the code and memory to get much worse performance? Because 'throw 1000 pentiums in a room' is already there to solve the easily parallel problems. That they are already there is the only reason to use them for solving a dynamic problem.
These ranking are based on LINPACK doing traditional operations like solving linear equations, so supercomputers like the Cray MTA aren't even listed even though for some grand challenges they destroy everything else, for example when doing dynamic mesh weather simluations. Each processor on the memory grid has 128 processor threads where the active thread switches every cycle (so memory fetch has huge latency). This lets it have a unified memory model and still have extremely high throughput.
So the MTA can adjust the mesh to compute the tornado in very fine detail while using far fewer points for the huge swaths of calmer weather around it. Traditional supercomputers can't do that well since just distributing the data points to each processor is so much overhead.
If anything, there was something far more insidious going on elsewhere and this was an attempt to divert the all powerful Slashdot crowd's attention to something worthless.
You mean like installing a traffic camera on Sesame Street to catch the liberal bias? Or the new Big Bird Sandwich at Hardee's?
Only like 5% max of the people should be republican; the rest are uneducated, uninformed, or bigots. That's why eliminating mass education will always trump non-skippable commercials in tivo.
Yes, if instead of 'plain' blocks you get combinations such as "A xor B" then knowing A you can get B and vice versa. So you can re-create hard to find blocks from easy to find ones.
What they don't mention is that it may improve the network bandwidth, but it trades it for much more work on the client. You can't just write A^D to it's final location in the file until you know A or D, so this has to be stored someplace. And during normal operation instead of just reading the block the other peer requested and sending it, the software has to read two or more blocks to combine them (block to combine with could be a recently received one, but still).
So in the end it doesn't reduce the amount of information send/received since ultimately each client has to receive the whole file (see information theory). So you are guarenteed at least several times more disk access and a lot more memory usage for your download, but it may finish sooner if the torrent can't provide some blocks quickly, which only seems to be the case really with a low-bandwidth tracker.
It's just like in Asimov's robots and empire books where people become more and more isolated, to the point where they don't even want to communicate with their neighbors through holographms because even an image is too icky and uncomfortable.
People don't talk to their neighbors, now they won't go to a movie because other people are making them uncomfortable basically just by being there. I guess the next step would be restaurants that have rooms instead of tables. Maybe a virtual church pew or virtual t-ball?
The truth is that they usually copy other research, tweak it up a bit (usually making it worse), and pretend that they invented it in the first place. Typical Microsoft... it must be something in the water up there.
In this case, the original is Tapestry, published at latest Apr 2001, followed by Pastry (hence the name) which was "done in part while visiting Microsoft Research, Cambridge, UK". Sounds to me like the main "innovative" part was providing a few computers. Meanwhile, the really new ideas (ala Chord) come from other places.
What would be better would be some form of patent jury. Select 12 people from the jury pool and treat the patent application kinda like a trial. If the applicant can convince 12 laymen, beyond a reasonable doubt, that the patent is non-obvious and innovative then they grant the application.
Then you get some retarded 'one-click' patent and there better be a halluva case put on for it or the jury will just laugh at it. It would automatically make the application have to be clear, because what jury is going to find for a patent they can't understand? Normal people get irritated by fancy language and take it out on whoever is doing it. You might get some advanced science patents rejected because the applicant can't teach normal people enough to understand whether it is a novel idea or not, but if you can't learn some normal person enough to tell how is a government worker going to be any better?
This is kinda a joke idea, but it gets to the heart of what's really missing from the process: the judgement call. Patent reviewers should be able to reject an application because the wording is too complicated, or because they just feel it is obvious, or even just not in the public interest -- not just yes/no based on existence of easy-to-find prior art. Give the same application randomly to several reviewers and use that to weed out the bad clerks (the ones that always deny no matter what, etc).
Doing either of the above might seem like a lot more cost, but I doubt it. When companies can no longer patent anything by making the application artificially complex or for something obvious there will be a LOT fewer application. Plus it will be worth any cost just to get readable patents.
With an OS written in a safe language, for safe languages, everything runs in ring 0. You don't have to use page tables; you can if you want to, with no requirement for any more assembly than otherwise.
There are plenty of people who could use a 'free' extra computer for browsing the web. It's like back when kids had to share the phone -- even one line per kid wasn't enough. So now instead of having to share whatever computers you have (maybe none) or buying a $300 wal-mart computer just to get the rugrats out of your hair they can just use the PS3 to do it; it's got an ethernet connection anyway to play on-line games.
It's not like setting up Linux for PPC to boot to a blank screen with a web browser requires much investment. And you get the geek vote, can sell a few more peripherals, and make the parents happy. What's not to like about it?
They should ship it with a knoppix-like distro on DVD. With that much space they could put basically everything in the known, open-source universe on it. Could even use the memory cards for some small amounts of data.
Yes, clearly machines running Smalltalk and LISP kernels never existed. And squeak developers are lying when they say its virtual machine is written in smalltalk.
And the reason why
for (x=0; x < 10000000; x++)
getpid();
takes 1 second due to system call overhead instead of 0.001 seconds is because C is such a great language for operating systems... hint: it's one instruction in a "safe" OS (ie not C/C++).
Parent:
Java and C# are slow because Python is slow
And that's suppose to be insightful? Python is slow. Java and C# are not. The only reason these languages show up lower in benchmarks are array access checks and, for Java, no stack-based variables.
Basically the question of keyboard vs mouse comes down to analog vs. digital. We use a keyboard to type characters because, for a computer, they are digital; there's no ascii code for "C that's looks kinda like a G". We use a mouse to do graphic art because a brush stroke is not a simple line. We use the keyboard to go forward and strafe in a FPS because it's either full-on or not, but a mouse for aiming since rate of rotation is continuously variable.