Actually, monolithic kernels will always be faster... in fact why not make all software monolithic? What I am talking about is running all programs in the kernel address space with simple function calls to kernel services. That would make the computer much faster, and it can be done.
If the entire operating system were written in a safe language such as Java or C# ("managed" code only) then the performance impact from syscalls, virtual memory (TLB flush/lookup), complicated task switching, and extra copies of data from/to the kernel would be almost entirely eliminated. A safe language is one that does not allow arbitrary pointers.
FYI, in a linux 2.6 kernel on a 512 meg machine 4 megs is taken just to have page tables -- not even including the overhead when processes actually add pages to their memory spaces, just to have support for VM in the first place. Syscalls take ~1000x longer than normaly functions, so they are always going to be a bottleneck. And when you call a syscall that takes a data parameter (string for instance) the data is in the best case copied (in the worst case the kernel sets the address of the reading instructions in a table, then a page fault happens and the fault handler checks the table to see if the access was okay). IO using read/write is always copied at least twice, and even mmap suffers from a lot of overhead from the kernel managing the pages.
Basically kernels written in C or other archaic systems programming language are needlessly slowing down the computer a LOT. With a safe language for instance, instead of using the virtual memory to force programs to not mess with each other, they simply can't do that so the VM can be used for other things. One nice performance enhancement is to allocate all memory (objects) in a 'new' zone and use VM to track what pages have been written to; when the 'new' zone fills up only pages that have been written to are checked for references during garbage collection. So basically you could do 1 billion memory allocations of arbitrary sizes and it would take only 1 billion instructions (each allocation increments an integer and that's all). Also, "system" calls are then just normal method calls and can even be inlined, so instead of getpid() taking the time of 1000 instructions it could easily take only 1 (direct inlined access to the variable).
So lots of people will mod this down since they assume that the low-level details like cache lines are more important than oh, say, free memory management. But I got some news: a few minor tweaks and you can do all that same low-level crap in Java or managed C# and get all the benefits of a safe kernel.
WTF with saying holograms are impossible because they have to be on a flat surface? We already have displays that rotate, where you don't really see the rotating mirror but you see the 3d image. Also, it should be easy to make a system that uses a matrix of 'holographic dust motes' to reflect parts of the image in 3-space; it's not like the holographs in Star Wars are life-like anyway.
Really, what is the difference between foo.bar = baz and foo->setBar(baz)?
It's basically the same difference as between "x=5" and "int x=5". In the Java version, you explicitly say 'this is NOT a direct data access' so you as the caller know, for instance, that retrieving that value may have side-effects or return a different value. For example, in Java code "obj.getRandom()" you would expect that the value would be different for each call whereas for "obj.random" that it would not change by reading that value.
Java developers are used to the code telling you exactly what it does without any ambiguity -- that's why they generally frown on operator overloading and automatic type conversions. Smalltalk, Ruby, and Python developers are used to the code looking simple, but having to basically know the whole program to know anything about what is really going on -- that's why they are generally used for scripting and either small-scale or very tighly integrated programs. C++ developers are on crack, because they have to know the whole program to know what a piece of code does AND it looks like crap.
Suddenly needing to mirror an API's functionality - especially one as big as the entirety of the JVM's data-processing infrastructure.
Personally I would much rather re-implement the Java API than re-implement OpenOffice. The Java standard library is fairly simple and the behavior is all documented, it's just that there is a lot of it. OpenOffice on the other hand is very complex and huge.
The reason classpath hasn't caught up is because they let only a tiny fraction of developers work on it that have never seen Sun sourcecode. Since the source codes with Java and any competent Java developer looks at the source from time to time this is a pretty severe limitation. If the Java API needed to be cloned quickly they could relax their clean-room requirements and it would get done in no time.
I'd use Python. Java is slow too, slower in practice since it makes much less use of native code.
What's scary is that you are freakin' serious. First off, there's nothing similar to Java that runs faster at raw performance numbers (method calls/second, numerical speed, GC). Python is much slower in that respect. Even the leading Smalltalk implementations are 1/4 the performance of Java at object-oriented benchmarks like method call overhead. Smalltalks are similar to Python in being dynamic object-oriented languages, but have had a LOT more optimization work done. Microsoft does everything they can to prevent non-funded C# benchmarks from being released, but even their C# is significantly slower performance-wise in running "managed code" (mono is a non-contender).
You're right that Python can be faster, mostly at scripting, because of using native code in more direct ways, but for something like OO.o where there is a LOT of code and quite a bit of math (laying out all that data, updating spreadsheets) realistically a pure-python implementation would probably be around 1/20th the speed of a Java one. FYI, Python runs significantly faster than Jython/JPython because the Java virtual machine is not designed for dynamic ("message passing") form of OO... but running the quivalent code in Java and Python, and Java will be the clear winner.
And oh yeah you think Mono is faster because the Language shootout says so? Or Java is slow? Take for example the word-counting benchmark for C, C#, and Java. Notice that the Java version uses the system locale's definition of whitespace where as the C# version hard-codes checks against space, \n, and \t? Or that the C version uses freaking table of sums to avoid branching? Under the hood Java is doing three method calls, an &, and a compare is almost as fast as Mono doing just 3 simple integer comparisons. Not that the language shootout is even fair... for instance it should compare throughput by increasing the number of iterations until it takes more than a certain time (so if C is 5x faster on a benchmark it does 5x more iterations). When even this minor scripting is too difficult to do it doesn't inspire much confidence in the results. Without this change they have lots of granularity errors and measuring of startup time on the fast end.
So yeah mod me down because this is a rant... but I'm just tired of the ignorant repeating over and over that Java is slow, when it's really the fastest of its kind.
while I agree that such things tend to "creep people out", what is the fundamental thing that an "anti-stalking law" is addressing? Is it the "peace of mind" of citizens?
It's most definitely not the "peace of mind" of citizens, as that is impossible to legislate. The problem with stalking is that somebody else knows where you are, what your habits are, and when you are vulnerable. Or in other words, "knowledge is power". We assume somebody paying so close attention to your daily life is doing so without your best interest in mind, and that something bad will result.
The idea behind anti-stalking legislation is to protect this personal information; collect that information illegally and you wind up safely behind bars. So a device that broadcasts your information, technically readable passively from miles away, is at best sabotaging personal safety. From this POV, Real ID is a clear negative.
The interesting thing is that in these "doomsday" scenarios about restricting rights and requiring cars that require identification and all that is that, at some point, the populace will start to vote down things, and call for reform.
What's really more interesting is the denial that slights a "scary" conclusion. We already have cars that will not turn over if the measured blood-alcohol content is too high. We have financial institutions that turn off credit when non-typical transactions are made. These types of systems will be combined if current trends continue. If people do not want a society where they can be turned off by fliping a bit then they need to understand how it will come about, and Real ID is a very good start down that path.
If somebody were to follow you around all day, everyday... from your house to your work to the convienience store, and anywhere else, would you get creeped out? Or more accurately, if you knew somebody was doing this but couldn't see them (they sent you summaries of what you did that day or something) would you like that? Would you want to stop them from doing this by invoking some anti-stalking law?
If you would not like somebody following you everywhere in this way then you are either against the Real ID or feigning ignorance.
But fundamentally the issue is whether you think obeying laws should be a person's responsibility or something enforced mechanically, because ultimately Real ID is about the latter. Seriously, how many war funding bills do you think it will take before your car will refuse to start without reading your id card first and checking wirelessly against a national "ok-to-drive" list? Or for that matter before the voting booth will require a machine-readable ID before allowing you to place your 'anonymous' vote? Do you want to be mechanically excluded from virtually everything with flip of a bit because some CITI thinks your daily patterns changed too much and requires an explation first, or do you want humans to always be in the loop?
The more you actually think about the ramifications the more you should be against this id.
Belief in God and evolution need not be mutually exclusive. That being said, evolution is as much a theory as creationism, and some may say it evolution relies on faith just as much (if not more) than creationism.
How can anything be more on faith than "god did it", or the non-theistic equivalent, "it just is, now shut up"?
1. God gave you a brain. 2. Not using your god-given talents is a deadly sin (sloth) 3. God layed down a consistent history of millions of years.
But he expects you pretend creationism, funny hats, and ignorance is part of his plan? You just can't win -- either you are a sinner for thinking or a sinner for lack of faith. Or maybe you are just wrong about a lot of things.
Sinners burn in hell, BTW. Forever. So choose wisely...
So the new shuttle will look like the top of the old shuttle and sit on a giant disposable rocket. How completely lame.
There is a huge waste of fuel right at the ground, since the gravity is much stronger and it is starting at a standstill. So why are we still wasting all this fuel that is in the rocket to get it moving? Why haven't we come up with something better, such as a freakin' launchpad that springs upward to give extra momentum? Or a fuel hose or something. Okay those wouldn't really work, but there has to be something better than just using vast amounts of fuel.
Dude your "business logic" is totally backward on this one. First of all, for an app like this users don't give a rat's ass about whether the window resizes at 300 fps with flicker or 10 fps without flicker; consider that kazaa was a hit even though it was ungodly slow. Sometimes it took seconds to switch tabs and it regularly took basically all of the computer's resources. People still used it because it just worked and it worked well.
Why do you think people stopped using the C-based bittorrent clients? It's because they didn't "just work". They didn't let you easily manage more than one stream, or throttle the bandwidth, or give nice-looking feedback on what parts were done, or recover from errors (ie not just die all the sudden), or support plug-ins, or have a built-in http server to check status, or work cross-platform, etc.
It would take a long time to make an interface as nice as Azureus in wxPython because writing widgets that display what chunks of the file are downloaded, the bandwith charts, etc and making it all update in realtime and stay consistent with your non-python core code would not be a simple task. Managing lots of multithreaded channels in C (or C++) and making it efficient and reliable would also not happen; your app would crash unexpectedly because doing that in those languages takes a lot of work. In Java it might take a day to add plug-in support and, if you wanted them to, the plug-ins could do basically any other part of the program could. That's essentially impossible in C, and very risky in a scripting language (since there are basically no sanity checks whatsoever).
So yeah, when you want to sell some complicated IT "solution", wxPython + C is a "good" choice. But for something like Azureus Java is really the best choice.
FYI, I was talking about the anonymous coward poster one above your post. Somehow slashdot put my reply under yours instead of the one about SUVs and such... I could swear I hit reply to the AC one but I guess not? Anyway hope that clears up your non-neocon-ness.
hey aren't even trucks. Hell, half of what is sold as a truck isn't a truck. Trucks can haul sofas. Trucks can haul 8'x4' sheets of plywood. If it cannot do both of those, even with the tailgate open, it's not a truck.... People are fucking morons
Nice. You and the other posters prove my point: I call them trucks and the people replying fly off the handle. "fuck" this, "moron" that. So these vehicles are not "pickup trucks" or "flatbed trucks". Call them "4-door trucks" if luxury truck really burns you up that badly. But regardless of your ranting they are fucking trucks; most are built on a truck frame and they are classified as trucks by weight -- the ones people object to anyway.
Instead of an "SUV" call it a "personal luxury truck" or even "urban truck", both of which are far more accurate names, and now suddenly you are responsible for defending why a luxury truck is good rather than "lefties" having to defend why it is evil. I call them trucks, because that's what they are; you call them SUVs because you want them to sound nice and harmless in your neo-con, politically-correct world.
Lefties need to stop talking about environmentalism and instead keep using phrases like "filth peddlers", against nature", "against cleanliness", or "companies who defile the holy planet". Get on FOX's propoganda channel and talk about how the "filth industry" is "graying our churches". Fight fire with fire.
You just posted to slashdot that you use IE... nevermind that you also prefer a 10-year-old JVM. Maybe it's just me, but highly I recommend learning something new instead of praying "JCobol" will stretch out your IT career until retirement.
About Project Looking Glass, Sun didn't "really take the right path" since it was done by one guy in his spare time. It really goes to show the productivity gain of using Java (or equivalent) -- it's not like other people in the Unix/X world haven't implemented similar eye-candy, but the difference is that implementing the fine details in C/C++ is a nightmare of complexity so you just get individual hacks like the 'wobbly window'. Leave it to others to implement a 'dock' for istance.
Many posts praise X windows' network transparency, but the fact is that it is too slow for realtime games and bit-movers like VNC are fast enough that X's transparency is of little real benefit. Sure current VNC's are slowish, especially when they lack a driver to detect dirty regions, but having used Radmin on windows I can tell you this model is perfectly workable (radmin is that much better than even tight VNC). Also note that the Java VNC applet is faster than native linux vnc (try playing a video using each).
It's not that I am a Java bigot so much as trying to make the point that a moderm X server is not concerned at all with low-level, for-loop performance; it's entire job these days is managing little bits of information (window dimensions, events/listeners, properties, etc). Implementing that in a complicated language like C (or C++) and having a protocol instead of an API is just too archaic these days. Manual memory management combined with lots of fine-grained data and structures is just ridiculous. It's ridiculous.
And so what if I mentioned Java? Use freakin' mono if you want, but there's no two ways about it: the X server is too old and archaic for modern interfaces.
Sure we could build a giant nuke and send it up there, but why not instead build a giant pyramid with a laser to alter the orbit? Then it's reusable for the next asteroid.
I mean isn't that the founding fathers were trying to tell us when they designed the $1 bill? Isn't that what Kirk and Miramonte(sp) did to save her planet? Maybe our eulogy will be, "they didn't learn from their historical records"; a berrylium sphere should be enough to power the laser.
As far ask I can tell, Tridge slowed down kernel development for everybody
You missed the point BIG TIME. Tridge did not do jack except to create. McVoy slowed down kernel development by taking away.
You don't blame somebody for doing something positive and constructive just because somebody else may get upset and throw down. How hard is that to comprehend?
Basically you would like to know all about his motivations. Who the f*ck cares? The entire problem is a hissy fit about somebody reverse-engineering a protocol and Tridge isn't the hissy.
But to answer for him anyway:
Why did he do it? Because he wanted to. Is OSDL paying for it? Ask OSDL. Why he kept going when OSDL promised he'd stop? He's not OSDL. Was it worth it? Ask McVoy. Why was reverse-engineering the only way? Because of the BitKeeper license. Will he keep going with the project? If Linux falls back to BitKeeper.
Seriously this is just pissed-off.com 101. Reverse-engineering a protocol is not wrong, immoral or impolite. It does not require justification. Purposely keeping a protocol closed however, does.
Unix permissions are actually better anyway because they are much easier to work with. It's very easy to write shell scripts that deals with user/group/other permission, see what the permissions are in output from ls, modify in GUI dialogs (see Finder's Info panel for example). If also lets the entire be specified in a fixed-size integer in the inode, which makes file access faster.
What's needed is old unix permissions + ACLs to handle the exceptions. So the ls output might be: drwxr-xr-x+... with the + to indicate ACLs are present for the file.
Nice... are they still refusing to give credit if the description is not clear one way or the other? Last I heard the policy was still "there's only one right answer; you should have asked for clarification during the contest" instead of "ok that's a different but still correct answer here's your points".
Funny... but much like the recent elections we'll just never know since, last time I checked, ACM does not release the test data or the solutions each team came up with. There's no independent verification possible for the results since the raw data is not available.
Maybe they put one point at 0,0 and you got a divide by zero error? ACM put in all kinds of test data like that which is to any sane person completely impossible for the given question. When I was in the regionals a LONG time ago the ACM actually rescored one of the problems after the contest was over, adding extra test data so another team's problem would pass but ours would not (there was a conflict with the rules and apparently they thought it was easier to just cheat). We were hosting that one which is the only reason we found out.
Overall I don't put much stock in the results because it's really more of a contest about robotic perfectionism. Unlike what people might expect there is extremely little creativity or problem-solving involved; each team has huge books of problems that they laboriously solve over and over again and there are never any fundamentally new problems in the competitions. I mean not like they could come up with an entirely new type of problem for each questions, but they always follow the same pattern: each problem has 1 fundamental approach you have to use (dynamic programming, graph-coloring, pattern-matching, monte-carlo) and then it's solved. Combine that with not telling any clues about why the program failed and it's really geared towards more robotic programmers. I got out of it precisely because there was virtually no creativity or thinking involved at all, at the professional level.
Also it's virtually impossible to detect cheating... if you watch these people, they basically start coding right from the start anyway so if you already knew the problem and solution there would be little difference to see, it would just look like that team was really good. Or maybe you see test data, or somebody elbows you and says 'be sure to check for 0,0 on the mars problem'.
A much better approach was done on topcode.com... there you get to see the test data and why your program failed. Then afterwards other contestants get to look at your code for a while and purposely try to break it with their own (valid) test cases. And you get bonus points for breaking other people's programs.
Slashdot Mirror
Actually, monolithic kernels will always be faster... in fact why not make all software monolithic? What I am talking about is running all programs in the kernel address space with simple function calls to kernel services. That would make the computer much faster, and it can be done.
If the entire operating system were written in a safe language such as Java or C# ("managed" code only) then the performance impact from syscalls, virtual memory (TLB flush/lookup), complicated task switching, and extra copies of data from/to the kernel would be almost entirely eliminated. A safe language is one that does not allow arbitrary pointers.
FYI, in a linux 2.6 kernel on a 512 meg machine 4 megs is taken just to have page tables -- not even including the overhead when processes actually add pages to their memory spaces, just to have support for VM in the first place. Syscalls take ~1000x longer than normaly functions, so they are always going to be a bottleneck. And when you call a syscall that takes a data parameter (string for instance) the data is in the best case copied (in the worst case the kernel sets the address of the reading instructions in a table, then a page fault happens and the fault handler checks the table to see if the access was okay). IO using read/write is always copied at least twice, and even mmap suffers from a lot of overhead from the kernel managing the pages.
Basically kernels written in C or other archaic systems programming language are needlessly slowing down the computer a LOT. With a safe language for instance, instead of using the virtual memory to force programs to not mess with each other, they simply can't do that so the VM can be used for other things. One nice performance enhancement is to allocate all memory (objects) in a 'new' zone and use VM to track what pages have been written to; when the 'new' zone fills up only pages that have been written to are checked for references during garbage collection. So basically you could do 1 billion memory allocations of arbitrary sizes and it would take only 1 billion instructions (each allocation increments an integer and that's all). Also, "system" calls are then just normal method calls and can even be inlined, so instead of getpid() taking the time of 1000 instructions it could easily take only 1 (direct inlined access to the variable).
So lots of people will mod this down since they assume that the low-level details like cache lines are more important than oh, say, free memory management. But I got some news: a few minor tweaks and you can do all that same low-level crap in Java or managed C# and get all the benefits of a safe kernel.
WTF with saying holograms are impossible because they have to be on a flat surface? We already have displays that rotate, where you don't really see the rotating mirror but you see the 3d image. Also, it should be easy to make a system that uses a matrix of 'holographic dust motes' to reflect parts of the image in 3-space; it's not like the holographs in Star Wars are life-like anyway.
Really, what is the difference between foo.bar = baz and foo->setBar(baz)?
It's basically the same difference as between "x=5" and "int x=5". In the Java version, you explicitly say 'this is NOT a direct data access' so you as the caller know, for instance, that retrieving that value may have side-effects or return a different value. For example, in Java code "obj.getRandom()" you would expect that the value would be different for each call whereas for "obj.random" that it would not change by reading that value.
Java developers are used to the code telling you exactly what it does without any ambiguity -- that's why they generally frown on operator overloading and automatic type conversions. Smalltalk, Ruby, and Python developers are used to the code looking simple, but having to basically know the whole program to know anything about what is really going on -- that's why they are generally used for scripting and either small-scale or very tighly integrated programs. C++ developers are on crack, because they have to know the whole program to know what a piece of code does AND it looks like crap.
Personally I would much rather re-implement the Java API than re-implement OpenOffice. The Java standard library is fairly simple and the behavior is all documented, it's just that there is a lot of it. OpenOffice on the other hand is very complex and huge.
The reason classpath hasn't caught up is because they let only a tiny fraction of developers work on it that have never seen Sun sourcecode. Since the source codes with Java and any competent Java developer looks at the source from time to time this is a pretty severe limitation. If the Java API needed to be cloned quickly they could relax their clean-room requirements and it would get done in no time.
What's scary is that you are freakin' serious. First off, there's nothing similar to Java that runs faster at raw performance numbers (method calls/second, numerical speed, GC). Python is much slower in that respect. Even the leading Smalltalk implementations are 1/4 the performance of Java at object-oriented benchmarks like method call overhead. Smalltalks are similar to Python in being dynamic object-oriented languages, but have had a LOT more optimization work done. Microsoft does everything they can to prevent non-funded C# benchmarks from being released, but even their C# is significantly slower performance-wise in running "managed code" (mono is a non-contender).
You're right that Python can be faster, mostly at scripting, because of using native code in more direct ways, but for something like OO.o where there is a LOT of code and quite a bit of math (laying out all that data, updating spreadsheets) realistically a pure-python implementation would probably be around 1/20th the speed of a Java one. FYI, Python runs significantly faster than Jython/JPython because the Java virtual machine is not designed for dynamic ("message passing") form of OO... but running the quivalent code in Java and Python, and Java will be the clear winner.
And oh yeah you think Mono is faster because the Language shootout says so? Or Java is slow? Take for example the word-counting benchmark for C, C#, and Java. Notice that the Java version uses the system locale's definition of whitespace where as the C# version hard-codes checks against space, \n, and \t? Or that the C version uses freaking table of sums to avoid branching? Under the hood Java is doing three method calls, an &, and a compare is almost as fast as Mono doing just 3 simple integer comparisons. Not that the language shootout is even fair... for instance it should compare throughput by increasing the number of iterations until it takes more than a certain time (so if C is 5x faster on a benchmark it does 5x more iterations). When even this minor scripting is too difficult to do it doesn't inspire much confidence in the results. Without this change they have lots of granularity errors and measuring of startup time on the fast end.
So yeah mod me down because this is a rant... but I'm just tired of the ignorant repeating over and over that Java is slow, when it's really the fastest of its kind.
It's most definitely not the "peace of mind" of citizens, as that is impossible to legislate. The problem with stalking is that somebody else knows where you are, what your habits are, and when you are vulnerable. Or in other words, "knowledge is power". We assume somebody paying so close attention to your daily life is doing so without your best interest in mind, and that something bad will result.
The idea behind anti-stalking legislation is to protect this personal information; collect that information illegally and you wind up safely behind bars. So a device that broadcasts your information, technically readable passively from miles away, is at best sabotaging personal safety. From this POV, Real ID is a clear negative.
What's really more interesting is the denial that slights a "scary" conclusion. We already have cars that will not turn over if the measured blood-alcohol content is too high. We have financial institutions that turn off credit when non-typical transactions are made. These types of systems will be combined if current trends continue. If people do not want a society where they can be turned off by fliping a bit then they need to understand how it will come about, and Real ID is a very good start down that path.
The privacy argument is really pretty simple:
If somebody were to follow you around all day, everyday... from your house to your work to the convienience store, and anywhere else, would you get creeped out? Or more accurately, if you knew somebody was doing this but couldn't see them (they sent you summaries of what you did that day or something) would you like that? Would you want to stop them from doing this by invoking some anti-stalking law?
If you would not like somebody following you everywhere in this way then you are either against the Real ID or feigning ignorance.
But fundamentally the issue is whether you think obeying laws should be a person's responsibility or something enforced mechanically, because ultimately Real ID is about the latter. Seriously, how many war funding bills do you think it will take before your car will refuse to start without reading your id card first and checking wirelessly against a national "ok-to-drive" list? Or for that matter before the voting booth will require a machine-readable ID before allowing you to place your 'anonymous' vote? Do you want to be mechanically excluded from virtually everything with flip of a bit because some CITI thinks your daily patterns changed too much and requires an explation first, or do you want humans to always be in the loop?
The more you actually think about the ramifications the more you should be against this id.
Belief in God and evolution need not be mutually exclusive. That being said, evolution is as much a theory as creationism, and some may say it evolution relies on faith just as much (if not more) than creationism.
How can anything be more on faith than "god did it", or the non-theistic equivalent, "it just is, now shut up"?
1. God gave you a brain.
2. Not using your god-given talents is a deadly sin (sloth)
3. God layed down a consistent history of millions of years.
But he expects you pretend creationism, funny hats, and ignorance is part of his plan? You just can't win -- either you are a sinner for thinking or a sinner for lack of faith. Or maybe you are just wrong about a lot of things.
Sinners burn in hell, BTW. Forever. So choose wisely...
So the new shuttle will look like the top of the old shuttle and sit on a giant disposable rocket. How completely lame.
There is a huge waste of fuel right at the ground, since the gravity is much stronger and it is starting at a standstill. So why are we still wasting all this fuel that is in the rocket to get it moving? Why haven't we come up with something better, such as a freakin' launchpad that springs upward to give extra momentum? Or a fuel hose or something. Okay those wouldn't really work, but there has to be something better than just using vast amounts of fuel.
Dude your "business logic" is totally backward on this one. First of all, for an app like this users don't give a rat's ass about whether the window resizes at 300 fps with flicker or 10 fps without flicker; consider that kazaa was a hit even though it was ungodly slow. Sometimes it took seconds to switch tabs and it regularly took basically all of the computer's resources. People still used it because it just worked and it worked well.
Why do you think people stopped using the C-based bittorrent clients? It's because they didn't "just work". They didn't let you easily manage more than one stream, or throttle the bandwidth, or give nice-looking feedback on what parts were done, or recover from errors (ie not just die all the sudden), or support plug-ins, or have a built-in http server to check status, or work cross-platform, etc.
It would take a long time to make an interface as nice as Azureus in wxPython because writing widgets that display what chunks of the file are downloaded, the bandwith charts, etc and making it all update in realtime and stay consistent with your non-python core code would not be a simple task. Managing lots of multithreaded channels in C (or C++) and making it efficient and reliable would also not happen; your app would crash unexpectedly because doing that in those languages takes a lot of work. In Java it might take a day to add plug-in support and, if you wanted them to, the plug-ins could do basically any other part of the program could. That's essentially impossible in C, and very risky in a scripting language (since there are basically no sanity checks whatsoever).
So yeah, when you want to sell some complicated IT "solution", wxPython + C is a "good" choice. But for something like Azureus Java is really the best choice.
So which geek is man enough to donate 3 years in the pokey so the rest of use can download it on bittorrent? Any volunteers?
--
It's called the FECA Law because everybody knows it's crap.
FYI, I was talking about the anonymous coward poster one above your post. Somehow slashdot put my reply under yours instead of the one about SUVs and such... I could swear I hit reply to the AC one but I guess not? Anyway hope that clears up your non-neocon-ness.
hey aren't even trucks. Hell, half of what is sold as a truck isn't a truck. Trucks can haul sofas. Trucks can haul 8'x4' sheets of plywood. If it cannot do both of those, even with the tailgate open, it's not a truck. ... People are fucking morons
Nice. You and the other posters prove my point: I call them trucks and the people replying fly off the handle. "fuck" this, "moron" that. So these vehicles are not "pickup trucks" or "flatbed trucks". Call them "4-door trucks" if luxury truck really burns you up that badly. But regardless of your ranting they are fucking trucks; most are built on a truck frame and they are classified as trucks by weight -- the ones people object to anyway.
Instead of an "SUV" call it a "personal luxury truck" or even "urban truck", both of which are far more accurate names, and now suddenly you are responsible for defending why a luxury truck is good rather than "lefties" having to defend why it is evil. I call them trucks, because that's what they are; you call them SUVs because you want them to sound nice and harmless in your neo-con, politically-correct world.
Lefties need to stop talking about environmentalism and instead keep using phrases like "filth peddlers", against nature", "against cleanliness", or "companies who defile the holy planet". Get on FOX's propoganda channel and talk about how the "filth industry" is "graying our churches". Fight fire with fire.
You just posted to slashdot that you use IE... nevermind that you also prefer a 10-year-old JVM. Maybe it's just me, but highly I recommend learning something new instead of praying "JCobol" will stretch out your IT career until retirement.
About Project Looking Glass, Sun didn't "really take the right path" since it was done by one guy in his spare time. It really goes to show the productivity gain of using Java (or equivalent) -- it's not like other people in the Unix/X world haven't implemented similar eye-candy, but the difference is that implementing the fine details in C/C++ is a nightmare of complexity so you just get individual hacks like the 'wobbly window'. Leave it to others to implement a 'dock' for istance.
Many posts praise X windows' network transparency, but the fact is that it is too slow for realtime games and bit-movers like VNC are fast enough that X's transparency is of little real benefit. Sure current VNC's are slowish, especially when they lack a driver to detect dirty regions, but having used Radmin on windows I can tell you this model is perfectly workable (radmin is that much better than even tight VNC). Also note that the Java VNC applet is faster than native linux vnc (try playing a video using each).
It's not that I am a Java bigot so much as trying to make the point that a moderm X server is not concerned at all with low-level, for-loop performance; it's entire job these days is managing little bits of information (window dimensions, events/listeners, properties, etc). Implementing that in a complicated language like C (or C++) and having a protocol instead of an API is just too archaic these days. Manual memory management combined with lots of fine-grained data and structures is just ridiculous. It's ridiculous.
And so what if I mentioned Java? Use freakin' mono if you want, but there's no two ways about it: the X server is too old and archaic for modern interfaces.
Sure we could build a giant nuke and send it up there, but why not instead build a giant pyramid with a laser to alter the orbit? Then it's reusable for the next asteroid.
I mean isn't that the founding fathers were trying to tell us when they designed the $1 bill? Isn't that what Kirk and Miramonte(sp) did to save her planet? Maybe our eulogy will be, "they didn't learn from their historical records"; a berrylium sphere should be enough to power the laser.
Also it should be no problem to set up some mirrors to warm the base up to basically any temperature. The coldness is a non-issue.
As far ask I can tell, Tridge slowed down kernel development for everybody
You missed the point BIG TIME. Tridge did not do jack except to create. McVoy slowed down kernel development by taking away.
You don't blame somebody for doing something positive and constructive just because somebody else may get upset and throw down. How hard is that to comprehend?
Basically you would like to know all about his motivations. Who the f*ck cares? The entire problem is a hissy fit about somebody reverse-engineering a protocol and Tridge isn't the hissy.
But to answer for him anyway:
Why did he do it? Because he wanted to.
Is OSDL paying for it? Ask OSDL.
Why he kept going when OSDL promised he'd stop? He's not OSDL.
Was it worth it? Ask McVoy.
Why was reverse-engineering the only way? Because of the BitKeeper license.
Will he keep going with the project? If Linux falls back to BitKeeper.
Seriously this is just pissed-off.com 101. Reverse-engineering a protocol is not wrong, immoral or impolite. It does not require justification. Purposely keeping a protocol closed however, does.
Unix permissions are actually better anyway because they are much easier to work with. It's very easy to write shell scripts that deals with user/group/other permission, see what the permissions are in output from ls, modify in GUI dialogs (see Finder's Info panel for example). If also lets the entire be specified in a fixed-size integer in the inode, which makes file access faster.
... with the + to indicate ACLs are present for the file.
What's needed is old unix permissions + ACLs to handle the exceptions. So the ls output might be: drwxr-xr-x+
Nice... are they still refusing to give credit if the description is not clear one way or the other? Last I heard the policy was still "there's only one right answer; you should have asked for clarification during the contest" instead of "ok that's a different but still correct answer here's your points".
Funny... but much like the recent elections we'll just never know since, last time I checked, ACM does not release the test data or the solutions each team came up with. There's no independent verification possible for the results since the raw data is not available.
Maybe they put one point at 0,0 and you got a divide by zero error? ACM put in all kinds of test data like that which is to any sane person completely impossible for the given question. When I was in the regionals a LONG time ago the ACM actually rescored one of the problems after the contest was over, adding extra test data so another team's problem would pass but ours would not (there was a conflict with the rules and apparently they thought it was easier to just cheat). We were hosting that one which is the only reason we found out.
Overall I don't put much stock in the results because it's really more of a contest about robotic perfectionism. Unlike what people might expect there is extremely little creativity or problem-solving involved; each team has huge books of problems that they laboriously solve over and over again and there are never any fundamentally new problems in the competitions. I mean not like they could come up with an entirely new type of problem for each questions, but they always follow the same pattern: each problem has 1 fundamental approach you have to use (dynamic programming, graph-coloring, pattern-matching, monte-carlo) and then it's solved. Combine that with not telling any clues about why the program failed and it's really geared towards more robotic programmers. I got out of it precisely because there was virtually no creativity or thinking involved at all, at the professional level.
Also it's virtually impossible to detect cheating... if you watch these people, they basically start coding right from the start anyway so if you already knew the problem and solution there would be little difference to see, it would just look like that team was really good. Or maybe you see test data, or somebody elbows you and says 'be sure to check for 0,0 on the mars problem'.
A much better approach was done on topcode.com... there you get to see the test data and why your program failed. Then afterwards other contestants get to look at your code for a while and purposely try to break it with their own (valid) test cases. And you get bonus points for breaking other people's programs.