They say with an election with many measures that instead of reading it aloud it could be put up on the projector and with enough observers any error would be spotted. But really all you need is one observer with a video camera of the running tally and the vote itself, then they can review it in slow motion later on.
I have described a system like this for a long time, only using OCR instead of bar codes. Bar codes are better though since the really important part is the running total that observers can match against the vote -- how the computer reads the printed vote is not important at all as long as the counts match what is human-readable. I'm glad they have created this system as it really shows how ridiculous the diebolds and others are.
What I find really interesting is that if you add up the %difference between machine and paper in large towns for democrats that has strange values (clinton, obama, edwards) you get ~10%. For medium towns you get ~10%. For republicans only large towns are different, by ~20%.
This suggests a relatively simple "every 10 votes for candidate A change one to candidate B" type of scheme. One would use this type of method in a very simple computer (optical scan), or if fraud were accomplished by a virus in a touchscreen, or by a hardware modification say to the light sensors. For republicans the base rate could have simply been doubled.
Somebody mentioned the exit polls being correct in these districts, but exit polls have been known to change after the fact to better match the results.
And please, Quickly do the recount before these people start asking about where the money for the war was spent. There is no recount necessary, ever, except at the local polls. Any other kind of recount is just an excuse for fraud.
In any sane system the counting is done by hand at each local poll and verified by any concerned persons. They leave with their poll's count and can verify it against any tally. That's right, any tally has to give the original counts for each poll so they can be double-checked by the people that observed any particular poll. A recount can be done for any disputed poll location, but in any case all sides know the correct count since they have their own trusted observer at each poll.
At my polling location in northern virginia there are up to 10 people chosen by the elections officials that are allowed observe the memory cards from the computer voting being sent off to be counted. How could that voting not be rigged? Given human nature it's basically impossible that my vote is counts.
Debate anybody you can that is willing and able... I did this in newsgroups, nowadays I guess you have a blog war? I don't know if a similar environment still exists. This was great learning because in order to defend your point you need to do the research to really know what you are talking about. Then just keep taking more outlandish positions that you can still defend and win.
For example, when you say "smalltalk is slow at everything" to in smalltalk advocacy they are going to come back and say "JIT" and "30-bit integers" and a bunch of other hooey. You are going to need to hammer back about cycles to test flag bits and which optimizations are not available for dynamically typed VMs -- you need to have already prepared for these counters. And you should have some benchmarks already prepared in case they drop something you don't understand so you can drop a "but in practice" bomb while you work out an angle on it.
Or when you can defend a non-memory protected typesafe operating system (ie a java kernel) as a superior solution over the micro- and monolithic kernels of today. That kind of thing takes knowledge of all sorts of things from mmu, cache lines, data copying, gc, etc in order to pull off successfully. Unfortunately places like slashdot are not suitable for technical debates like that.
This is way more fun and educational than "hey let me learn about X just because it exists" or any class.
Passwords won't help you avoid traffic shaping and 'no server' rules from your ISP, but automatically changing port numbers and servers that no longer 'exist' when the ISP's batch process gets around to connect to them to look for 'unauthorized use' will.
It looks to me like Apple is coming out with the ultimate: a super-portable laptop that you slide into the side of a monitor and it becomes your main computer with your optical drive, full keyboard, mouse, and hard drive storing your large data (like most of your tunes and videos and stuff). And you access this data wirelessly when you remove it (to read web pages on the couch or whatever). You can probably even slide it into anybody's 'mac display' and get your files over the internet.
Why would they pre-announce an ultraportable tiny laptop with flash drive and no optical less than 2 weeks from mac world? I bet a little monkey king whispered in their ear that Apple is releasing something like this and they don't want to be a me-too. In any case we'll be seeing lots of these small screen + keyboard + flash laptops coming out soon. If not I'm going to regret not getting an eee already.
There is, and will always be, overhead associated with parallelization. It may sound great to say "oh, we can farm out parts of this data set to other cores!", but that requires a lot of start-up and tear-down synchronization. I think what you meant to say is that with os threads it requires a lot of effort and overhead. For example on Tera/Cray's MTA it took basically no extra overhead at all to run a loop in parallel over N hardware threads. The only 'hard' part was letting the compiler know which loops to do in parallel.
The problem with os threads is that the things the benefit the most from parallel processing are the finest grained, but the os threads are only usable for the coarsest grained problems. So, OS threads are generally only useful for concurrency and not for parallel execution. Ie meaning that os threads can let you do two mostly different 'tasks' at the same time (repainting the GUI while the data is being processed), but are really bad at actually making a single task run faster.
You can, sometimes, with incredible effort make os threads run one task faster. But that doesn't change the fact that they are a really really bad solution for this.
Soon we will be able to test 2^N possibilities in 2N time, but my question is where does that information come from? There's a lot of hand-wavyness on how that actually happens...
One possibility is that we ask the 'computer' of the universe to do too much computation and end up in an infinite loop, crashed universe, 'dark' part of a mandlebrot-like fractal, etc.
Another possibility is that the 'computer' of the universe will simply abort operations that take 'too long', the quality of our simulation will degrade, and our complex quantum math will result in randomish results.
And then there is the possibility held by quantum researchers that somehow the universe can magically perform any amount of complex computation with no cost at all. "Here a miracle occurs".
Somebody is in for a rude awakening. I hope that is us determining that we run in a simulation and not us finding out we've accidentally sucked the life out of the universe cracking somebody's encryption key.
We should conquer and colonize another planet first, then send active SETI signals from there instead. Send out signals from a planet -- lol.
Build a partial dyson sphere around a somewhat nearby star, even just a vast network of satellites, and use them to turn the light of the star on and off to send an unmistakable binary message. Occasionally this binary message can contain the encrypted 'log' of visitors, so that we can find out about them from any vantage point in the universe (but they ostensibly can't locate us like with some directional signal, unless they can trace our 'subspace signature' somehow).
This would over time 'draw' aliens to the star while giving some protection against hostile civilizations. We should be looking for something grand like this, not some 'hydrogen times pi' nonsense.
There is probably also a maximum amount of energy you can store per unit volume, though I'd guess they don't have that worked out yet. If you can input more energy than is lost over time then you could conceivable build up any amount of energy until... what happens? The iron spheres melt from heat? A hole opens in the time-space continuum and the Enterprise C comes through? What?
Ahmadinejade is pretty much an idiot (see no gays in Iran comment) who doesn't really have all that special of a record. Is he a threat to world civilization, probably not. He does, however, say enough dumb things that he gives political capital to his enemies in the west. Calling somebody who apparently was in the top 99.9% on his college entrance exams and with a degree in civil engineering and Ph.D in transportation engineering an idiot is 'pretty much' lame. He may not be wise, or may be too religiously conservative for us, but I seriously doubt he's so stupid. More likely he is pandering to the Arabs for good will by agreeing with them on the subjects they care most about. You know, the people that actually live in the same region.
It seems he gets mistranslated a lot too, like about the wiping off the map, or about there not being gays like in the US. Maybe he meant as in with their own parades and being in everybody's face... although I hear that the Iranians watching also laughed at that one. I don't know, but it sounds to me like an Al Gore "invented the internet" kind of spin.
All programmers criticize the code they inherit. The key point is what the criticisms are. As a rule of thumb:
* Low-level form and factor: The code is written by somebody of much lower ability, so the code is disorganized with lots of run-on functions. You can understand the code, but modifying or maintaining it is next to impossible just as speaking with invalid grammar is very difficult if you know better (ie "somebody sent up us the bomb", or repeating verbatim pretty much anything GWB says). * Syntax and naming: The code is roughly at your same level of ability. You can understand it and modify it, but you don't want to because it smells bad. * High-level structures: The code is written by a more skilled programmer. You probably do not understand why the code was written as it was even with documentation, and even if you do then changes you make will cause a lot of side-effects and unexpected errors. Sadly you should rewrite this code because you cannot make other than superficial changes since you fundamentally do not understand it.
Generally the code is at the lowest level you are complaining about.
Another common trait is to deny one's own faults. First of all, if somebody says something is "equally likely" as something else that's almost always some kind of rationalization. There are precious few things that are equally likely (or fair and balanced), and in this case any decent programmer should be able to determine immediately if there are some few ugly sections vs the whole program being a huge pile of crap.
Of course the BIG mistake is to only have one programmer. What happens when they take a break or leave? Everything stops. Another mistake is to have programmers of very different talent (as opposed to experience) working together. This invariably causes the very talented ones to leave and the poor ones are left with code they don't understand.
Network Neutrality is just a term coined to mean "the ISP doesn't mess with the traffic". As a consumer when a packet gets dropped you have no idea whether it was because of the destination or because of the protocol, so these are both covered under net neutrality. That's why we need legislation that makes all messing with packets regulated.
What comcast is doing is stupid for controlling bandwidth because the user can actually tell what happened. They are doing a favor for net neutrality advocates by being so clumsy since they could just silently drops ACKs and/or drop random packets for the targeted protocols and this would slow down connections without anybody being the wiser.
Firstly, I think your conclusion that "Java is much faster than C#" is very difficult to support... but the overall picture I see is that the performance of C# is in fact quite competitive with Java in terms of runtime performance. You can't post benchmarks of C#, macro or micro... enough said. Actual performance of CLR has to be hidden from view.
Value types: [...] Also, the complexity cost you note is small, as even Java still has value types. If you have to deal with both, then adding in structs isn't that costly, from a language and runtime view. You'd think... but in Java the bytecode specifically indicates each value type whereas the CLR does not (since there can be any number of value types). The cost of this to CLR is HUGE because makes it not interpretable and also very difficult to optimize... the CLR has to determine types for all values whereas the JVM has the actual type built right into the code. I can't stress enough how much more complex this makes the CLR implementation.
JIT-only:... I think MS thought the added complexity of interpretation+hotspot compliation wasn't worth it for them. It was a tradeoff, but I don't see it as a drastic one. Also, C# can still code-pitch if needed. It is probably harder. The primary benefits of hotspot (inlining and other optimizations across multiple methods) are effectively not possible in CLR due to the interactions between value types, generics, and the bytecode format. It's not that Microsoft does not want to do these, it's that they are not able to.
Real Generics:... C# 3.0 can do a ton of type-inference and more functional-like program as the type information of a delegate (or lambda expression) is kept and passed. Also, I'd like to see the reference for the CLR only inlining one deep. Give some real examples because as far as I've seen 'real' generics are useful in theory only. Reference to CLR inlining:
This is somewhat old, but from a person very close to the code. Note the extreme lack of inlining:
* nothing greather than 32 instructions * no virtual functions * nothing with flow control * nothing that catches exceptions or uses finally * nothing with structs as paramaters
The fundamental reason is that these things like generics and value types effectively multiply the complexity at each point. In other words, they 'screwed the pooch'. Java inlining is not restricted by any of the above.
If I want to store a list of half a million vectors and do some geometry with them, in Java the only real solution is to break the vectors apart and store them as floats, because there is just too much data manipulated if you use objects, which takes both a time and a storage toll. It also forces all your helper routines to take plain old float arrays - you might as well be writing C code, for all the type safety that gives you. You are talking about 'value' types and collections of them. Values are copies, so just write a VectorArray that stores them using arrays of Java primitive types. The overhead of creating small temporary objects when accessing these vectors will be real but negligible (since these objects do not last long). Yes, it's slightly annoying.
I did not say that there is no benefit to 'value' types, only that their benefit is outweighed by their cost. What good is it to have a value type when the methods you call on it are not inlined, or are only superficially inlined? Java can and does inline 5+ calls deep in some cases -- that can be a lot of extra time to cover these costs.
But it's kind of annoying that for years we have been told that this type of thing is not a problem at all, and that furthermore, that the only workaround is to put supreme faith in the JVM to bless us with everything we need. It's not that I disagree with that, but on the other hand the optimizations the JVM can do now is largely because they didn't add hacks to directly address these issues. That was my point. It's basically another example of Knuth's motto.
What's so interesting about it is that Microsoft's copy of Java, C#, was concerned about being the fastest language so they make a lot of hacky choices purely based on what they thought would be fastest. Things like:
* value types - now java can often automatically put objects on the stack and this makes the complexity cost of value types hardly worth the benefits.
* jit-only - C# thought that a jit would always be used because jit is 'faster', so their bytecode is not able to be interpreted effectively. This prevents the very efficient mixed-mode interpret followed by hotspot compile (for instance, Java can optimize the program using another core while it is running interpreted).
* 'real' generics - C# thought real generics would be faster by avoiding casts, but the complexity cost of following generic instance types prevents many optimizations such as method inlining that now save more time than casts (iirc CLR only inlined single methods less than 32 instructions and only if not overridden, vs Java inlining multiple method calls deep)
* embedded native code - C#'s bare-metal native code interface allows for faster access to small bits of native code, but it locks objects in place in memory a lot more making the gc more complicated... and so on.
In all these cases C# chose the way it thought was fastest but this made the CLR very complex. Java chose the way that was simplest but fast enough. And the end result is that Java is much faster than C# and a much simpler implementation.
by Jeremiah Cornelius (137) I love it how all the low-ids come out of the woodwork to discuss email and its spam problems... USENET, NNTP, nethack, vt52, and the finer points of X11 visual classes. Coincidence?
Let's go a few steps backward and remind everyone of the absurd EULAs everyone has agreed to when using proprietary software. They invalidate any moral authority one could possibly bring to a discussion about WoW's new scheme. Oh really... everyone? I use a magic marker to draw an big "X" on the monitor over the EULA, initial it, then take a picture. Sometimes if it's a particularly bad one I even draw a little bullet heading at the crossed-out text with caption "dodge this".
Which is the same way they do it in every other framework. Kindof. In Swing all of a GUI runs through the same event loop, so while something is processing an event all parts of the GUI are frozen. In other toolkits a lot of basic functions like redrawing are handled by the OS or by a separate thread that manages low-level gui 'controls'. In Swing you can have for instance a drop down list with tables as the entries instead of names. But since the GUI is are so flexible nothing can be done really while other events are being processed.
Also, some toolkits allow the application to 'cooperatively' multitask the event loop, for instance Qt has something like "eventLoop->processEvents(noUserInput)" that you can call from time to time during your long-running operation to repaint the GUI. Of course your application might crash because some event caused the object you are working on to be free'd. Or it might paint the wrong information, or do all kinds of badness.
Swing is actually a really freakin' awesome toolkit for creating the building blocks of a GUI and for creating new components. It's just really bad at being an application GUI since your application code is running in the same mix as all the little details of a component. What they should do is create a 'application GUI' layer on top with simpler component APIs that just handle the high-level logic of the component -- these can run in a separate thread so that all the layout and repaint can still happen while your slow processing code is busy. Like have a list component where you can add a freaking string entry without having to have some custom ListModel. If you need the low-level stuff only then do you need to worry about threads and repaints and all the other little details.
You know, as I start getting older I start to understand what the old people are thinking. For instance, a long time ago I saw a video of a guy caught in a house fire pacing up and down the sidewalk with smoke still coming up from what was left of his smouldering hair and strips of flesh hanging from his arms like a poorly wrapped mummy. The rescue workers were constantly yelling at him to keep standing so they could get the sanitary tarp out because all he could do say is he wanted to lie down and to make this most horrible of sounds.
This was real and even just watching it on the video burned it into my brain forever and I don't want it there. Not like a movie where even the most gruesome things are easily forgettable. Some people need to see it, like the rescue workers who actually experienced it. Regulation does not have to be censorship. At least give people, not just kids, the informed choice of whether they want to or not. The video I saw was NOT labeled like it would contain this kind of thing.
I think when you are younger you just don't realize how much things build up over time. It's not just one goatse or one body falling from the trade tower with a sack of potatoes thud, it's the totality. And when you get older maybe you'll also want to impart your wisdom not to know more of this than you should.
Dogma implies that people of faith are following something merely because it is pushed by a church and hammered into their skulls, not that people are capable of independent thought and coming to their own conclusions. That might be true but "cling to dogma" implies people of faith who can use independent thought and can come to their own conclusions but choose not to. Such as yourself.
The same way we don't tolerate murder just because the murderer had the capability to be compassionate, we don't tolerate religion on slashdot simply because the person has the capability of independent thought. It's not the capability that matters, but what you choose to actually do with it.
for x in $(seq 1 16400); do touch filename.$x; done mkdir copy cp filename.* copy/ bash:/bin/cp: Argument list too long
All these artificial limits are stupid and sure Vista is even more broken, but Unix has had this kind of problem for decades and instead of fixing it (ala plan 9) they just came up with stuff to work around it (xargs).
You're thinking on a much smaller scale than your first earlier implied (since you first referred the ideas in their most general form), and I think if I understand you now I don't necessarily disagree. I listed out three lines of optimization that were not being done:
1) using shared memory segments that the userspace and kernel use to avoid copying (ie mark read-only while in the kernel)
2) combining operations that take many syscalls into a single operation
3) running some user codes withing the kernel itself
and evidence showing their utility. I am not even the source of these ideas, and I only restrict anything down to a smaller scale because the 'larger' ideas have already been shot down as 'too hard' without any real reason why. I mean if a person honestly believes that readdir+stat (the moral equivalent of OS X getdirentries) is too much work or would require a complete rewrite then convincing them of any optimization at all that isn't say spelled out in POSIX is going to be a major accomplishment.
Sure, why would you create a DSL for every thing when you could use a GL one instead? The interface is already there, just have it use system calls like a process. That's not rocket science That is rocket science, in the sense that some kind of security model would have to be enforced to prevent malicious or careless users from borking the kernel. To avoid the overhead of constant checking, the security check would have to be done on the code itself when it is presented by the user, rather than on the code's runtime activity. The rocket science comparison here is particularly apt, since it's an old idea, has been demonstrated in practice, is routine for some uses (rockets take satellites into orbit; Java checks loaded bytecode to make sure it's safe for the VM), yet it is still only practical (so far) in a narrow range of applications. A DSL is much easier, because it can include a very limited set of abstractions and control flow facilities (or no flow control facilities at all.) The same could be said for a lot of kernel work. I would argue that a bytecode verifier is simple compared to many parts of the kernel -- real filesystems and memory management are particularly dense. Getting the complex interactions of mmap, read/write, disk cache, etc correct among all the different types of files and filesystems is far from simple and there have been many actual security flaws in this area in linux (the number is at least an order of magnitude more than flaws in the Java bytecode verifier for instance). It's not like just because there is potential for error it isn't worth doing.
Apparently there aren't kernel developers interested in doing these kinds of things, but I never said there were -- I just said that it would be a lot more fruitful than say getting a slightly better scheduler.
Don't, however, expect a kernel dev to go off on a tangent that is going to require large amounts of the kernel, some of which he may not have any interest in, to be replaced just because you think it might be a good idea. I linked to the paper to show that other people have demonstrated that it is a good idea. Kernel developers shouldn't care what I think, they should care about facts and about improving their system. Instead they dithering over registers and cache lines when the whole approach is grossly inefficient to begin with in many cases.
Programs need to take ~6000 cycles between system calls to have only a small 10% overhead just for making the calls, not even to mention the copying of data and setting up fault handlers and such. This is a crazy amount of overhead for some types of programs. And if you can switch a process in 100 cycles versus 2000 then the scheduler doesn't even need to be as fair.
Mind giving me and installing an electric engine to put in [my truck] Here you go. It's your truck, you put it in.
You act as if the entire kernel would have to be rewritten and maybe even userspace, but that is not so. They would need to make some changes like being able to do anything from an in-kernel thread that an application can, which is not too terribly far from the current Linux (as opposed to say FreeBSD which would require a *lot* of work to do this). Hell even just start with something simple like inotify (the design of which is absurd) and make it so programs can process events inside the kernel, making it actually be useful (see BPF).
Slashdot Mirror
They say with an election with many measures that instead of reading it aloud it could be put up on the projector and with enough observers any error would be spotted. But really all you need is one observer with a video camera of the running tally and the vote itself, then they can review it in slow motion later on.
I have described a system like this for a long time, only using OCR instead of bar codes. Bar codes are better though since the really important part is the running total that observers can match against the vote -- how the computer reads the printed vote is not important at all as long as the counts match what is human-readable. I'm glad they have created this system as it really shows how ridiculous the diebolds and others are.
What I find really interesting is that if you add up the %difference between machine and paper in large towns for democrats that has strange values (clinton, obama, edwards) you get ~10%. For medium towns you get ~10%. For republicans only large towns are different, by ~20%.
This suggests a relatively simple "every 10 votes for candidate A change one to candidate B" type of scheme. One would use this type of method in a very simple computer (optical scan), or if fraud were accomplished by a virus in a touchscreen, or by a hardware modification say to the light sensors. For republicans the base rate could have simply been doubled.
Somebody mentioned the exit polls being correct in these districts, but exit polls have been known to change after the fact to better match the results.
In any sane system the counting is done by hand at each local poll and verified by any concerned persons. They leave with their poll's count and can verify it against any tally. That's right, any tally has to give the original counts for each poll so they can be double-checked by the people that observed any particular poll. A recount can be done for any disputed poll location, but in any case all sides know the correct count since they have their own trusted observer at each poll.
At my polling location in northern virginia there are up to 10 people chosen by the elections officials that are allowed observe the memory cards from the computer voting being sent off to be counted. How could that voting not be rigged? Given human nature it's basically impossible that my vote is counts.
Debate anybody you can that is willing and able... I did this in newsgroups, nowadays I guess you have a blog war? I don't know if a similar environment still exists. This was great learning because in order to defend your point you need to do the research to really know what you are talking about. Then just keep taking more outlandish positions that you can still defend and win.
For example, when you say "smalltalk is slow at everything" to in smalltalk advocacy they are going to come back and say "JIT" and "30-bit integers" and a bunch of other hooey. You are going to need to hammer back about cycles to test flag bits and which optimizations are not available for dynamically typed VMs -- you need to have already prepared for these counters. And you should have some benchmarks already prepared in case they drop something you don't understand so you can drop a "but in practice" bomb while you work out an angle on it.
Or when you can defend a non-memory protected typesafe operating system (ie a java kernel) as a superior solution over the micro- and monolithic kernels of today. That kind of thing takes knowledge of all sorts of things from mmu, cache lines, data copying, gc, etc in order to pull off successfully. Unfortunately places like slashdot are not suitable for technical debates like that.
This is way more fun and educational than "hey let me learn about X just because it exists" or any class.
Passwords won't help you avoid traffic shaping and 'no server' rules from your ISP, but automatically changing port numbers and servers that no longer 'exist' when the ISP's batch process gets around to connect to them to look for 'unauthorized use' will.
Good point. But check out this Apple Patent.
It looks to me like Apple is coming out with the ultimate: a super-portable laptop that you slide into the side of a monitor and it becomes your main computer with your optical drive, full keyboard, mouse, and hard drive storing your large data (like most of your tunes and videos and stuff). And you access this data wirelessly when you remove it (to read web pages on the couch or whatever). You can probably even slide it into anybody's 'mac display' and get your files over the internet.
Why would they pre-announce an ultraportable tiny laptop with flash drive and no optical less than 2 weeks from mac world? I bet a little monkey king whispered in their ear that Apple is releasing something like this and they don't want to be a me-too. In any case we'll be seeing lots of these small screen + keyboard + flash laptops coming out soon. If not I'm going to regret not getting an eee already.
The problem with os threads is that the things the benefit the most from parallel processing are the finest grained, but the os threads are only usable for the coarsest grained problems. So, OS threads are generally only useful for concurrency and not for parallel execution. Ie meaning that os threads can let you do two mostly different 'tasks' at the same time (repainting the GUI while the data is being processed), but are really bad at actually making a single task run faster.
You can, sometimes, with incredible effort make os threads run one task faster. But that doesn't change the fact that they are a really really bad solution for this.
Soon we will be able to test 2^N possibilities in 2N time, but my question is where does that information come from? There's a lot of hand-wavyness on how that actually happens...
One possibility is that we ask the 'computer' of the universe to do too much computation and end up in an infinite loop, crashed universe, 'dark' part of a mandlebrot-like fractal, etc.
Another possibility is that the 'computer' of the universe will simply abort operations that take 'too long', the quality of our simulation will degrade, and our complex quantum math will result in randomish results.
And then there is the possibility held by quantum researchers that somehow the universe can magically perform any amount of complex computation with no cost at all. "Here a miracle occurs".
Somebody is in for a rude awakening. I hope that is us determining that we run in a simulation and not us finding out we've accidentally sucked the life out of the universe cracking somebody's encryption key.
Build a partial dyson sphere around a somewhat nearby star, even just a vast network of satellites, and use them to turn the light of the star on and off to send an unmistakable binary message. Occasionally this binary message can contain the encrypted 'log' of visitors, so that we can find out about them from any vantage point in the universe (but they ostensibly can't locate us like with some directional signal, unless they can trace our 'subspace signature' somehow).
This would over time 'draw' aliens to the star while giving some protection against hostile civilizations. We should be looking for something grand like this, not some 'hydrogen times pi' nonsense.
Some physicist please tell us what happens.
It seems he gets mistranslated a lot too, like about the wiping off the map, or about there not being gays like in the US. Maybe he meant as in with their own parades and being in everybody's face... although I hear that the Iranians watching also laughed at that one. I don't know, but it sounds to me like an Al Gore "invented the internet" kind of spin.
* Low-level form and factor: The code is written by somebody of much lower ability, so the code is disorganized with lots of run-on functions. You can understand the code, but modifying or maintaining it is next to impossible just as speaking with invalid grammar is very difficult if you know better (ie "somebody sent up us the bomb", or repeating verbatim pretty much anything GWB says).
* Syntax and naming: The code is roughly at your same level of ability. You can understand it and modify it, but you don't want to because it smells bad.
* High-level structures: The code is written by a more skilled programmer. You probably do not understand why the code was written as it was even with documentation, and even if you do then changes you make will cause a lot of side-effects and unexpected errors. Sadly you should rewrite this code because you cannot make other than superficial changes since you fundamentally do not understand it.
Generally the code is at the lowest level you are complaining about.
Another common trait is to deny one's own faults. First of all, if somebody says something is "equally likely" as something else that's almost always some kind of rationalization. There are precious few things that are equally likely (or fair and balanced), and in this case any decent programmer should be able to determine immediately if there are some few ugly sections vs the whole program being a huge pile of crap. Of course the BIG mistake is to only have one programmer. What happens when they take a break or leave? Everything stops. Another mistake is to have programmers of very different talent (as opposed to experience) working together. This invariably causes the very talented ones to leave and the poor ones are left with code they don't understand.
Network Neutrality is just a term coined to mean "the ISP doesn't mess with the traffic". As a consumer when a packet gets dropped you have no idea whether it was because of the destination or because of the protocol, so these are both covered under net neutrality. That's why we need legislation that makes all messing with packets regulated.
What comcast is doing is stupid for controlling bandwidth because the user can actually tell what happened. They are doing a favor for net neutrality advocates by being so clumsy since they could just silently drops ACKs and/or drop random packets for the targeted protocols and this would slow down connections without anybody being the wiser.
http://blogs.msdn.com/ericgu/archive/2004/01/29/64717.aspx
This is somewhat old, but from a person very close to the code. Note the extreme lack of inlining:
* nothing greather than 32 instructions
* no virtual functions
* nothing with flow control
* nothing that catches exceptions or uses finally
* nothing with structs as paramaters
The fundamental reason is that these things like generics and value types effectively multiply the complexity at each point. In other words, they 'screwed the pooch'. Java inlining is not restricted by any of the above.
I did not say that there is no benefit to 'value' types, only that their benefit is outweighed by their cost. What good is it to have a value type when the methods you call on it are not inlined, or are only superficially inlined? Java can and does inline 5+ calls deep in some cases -- that can be a lot of extra time to cover these costs. But it's kind of annoying that for years we have been told that this type of thing is not a problem at all, and that furthermore, that the only workaround is to put supreme faith in the JVM to bless us with everything we need. It's not that I disagree with that, but on the other hand the optimizations the JVM can do now is largely because they didn't add hacks to directly address these issues. That was my point. It's basically another example of Knuth's motto.
What's so interesting about it is that Microsoft's copy of Java, C#, was concerned about being the fastest language so they make a lot of hacky choices purely based on what they thought would be fastest. Things like:
.. and so on.
* value types - now java can often automatically put objects on the stack and this makes the complexity cost of value types hardly worth the benefits.
* jit-only - C# thought that a jit would always be used because jit is 'faster', so their bytecode is not able to be interpreted effectively. This prevents the very efficient mixed-mode interpret followed by hotspot compile (for instance, Java can optimize the program using another core while it is running interpreted).
* 'real' generics - C# thought real generics would be faster by avoiding casts, but the complexity cost of following generic instance types prevents many optimizations such as method inlining that now save more time than casts (iirc CLR only inlined single methods less than 32 instructions and only if not overridden, vs Java inlining multiple method calls deep)
* embedded native code - C#'s bare-metal native code interface allows for faster access to small bits of native code, but it locks objects in place in memory a lot more making the gc more complicated.
In all these cases C# chose the way it thought was fastest but this made the CLR very complex. Java chose the way that was simplest but fast enough. And the end result is that Java is much faster than C# and a much simpler implementation.
Also, some toolkits allow the application to 'cooperatively' multitask the event loop, for instance Qt has something like "eventLoop->processEvents(noUserInput)" that you can call from time to time during your long-running operation to repaint the GUI. Of course your application might crash because some event caused the object you are working on to be free'd. Or it might paint the wrong information, or do all kinds of badness.
Swing is actually a really freakin' awesome toolkit for creating the building blocks of a GUI and for creating new components. It's just really bad at being an application GUI since your application code is running in the same mix as all the little details of a component. What they should do is create a 'application GUI' layer on top with simpler component APIs that just handle the high-level logic of the component -- these can run in a separate thread so that all the layout and repaint can still happen while your slow processing code is busy. Like have a list component where you can add a freaking string entry without having to have some custom ListModel. If you need the low-level stuff only then do you need to worry about threads and repaints and all the other little details.
You know, as I start getting older I start to understand what the old people are thinking. For instance, a long time ago I saw a video of a guy caught in a house fire pacing up and down the sidewalk with smoke still coming up from what was left of his smouldering hair and strips of flesh hanging from his arms like a poorly wrapped mummy. The rescue workers were constantly yelling at him to keep standing so they could get the sanitary tarp out because all he could do say is he wanted to lie down and to make this most horrible of sounds.
This was real and even just watching it on the video burned it into my brain forever and I don't want it there. Not like a movie where even the most gruesome things are easily forgettable. Some people need to see it, like the rescue workers who actually experienced it. Regulation does not have to be censorship. At least give people, not just kids, the informed choice of whether they want to or not. The video I saw was NOT labeled like it would contain this kind of thing.
I think when you are younger you just don't realize how much things build up over time. It's not just one goatse or one body falling from the trade tower with a sack of potatoes thud, it's the totality. And when you get older maybe you'll also want to impart your wisdom not to know more of this than you should.
The same way we don't tolerate murder just because the murderer had the capability to be compassionate, we don't tolerate religion on slashdot simply because the person has the capability of independent thought. It's not the capability that matters, but what you choose to actually do with it.
for x in $(seq 1 16400); do touch filename.$x; done /bin/cp: Argument list too long
mkdir copy
cp filename.* copy/
bash:
All these artificial limits are stupid and sure Vista is even more broken, but Unix has had this kind of problem for decades and instead of fixing it (ala plan 9) they just came up with stuff to work around it (xargs).
1) using shared memory segments that the userspace and kernel use to avoid copying (ie mark read-only while in the kernel)
2) combining operations that take many syscalls into a single operation
3) running some user codes withing the kernel itself
and evidence showing their utility. I am not even the source of these ideas, and I only restrict anything down to a smaller scale because the 'larger' ideas have already been shot down as 'too hard' without any real reason why. I mean if a person honestly believes that readdir+stat (the moral equivalent of OS X getdirentries) is too much work or would require a complete rewrite then convincing them of any optimization at all that isn't say spelled out in POSIX is going to be a major accomplishment. Sure, why would you create a DSL for every thing when you could use a GL one instead? The interface is already there, just have it use system calls like a process. That's not rocket science That is rocket science, in the sense that some kind of security model would have to be enforced to prevent malicious or careless users from borking the kernel. To avoid the overhead of constant checking, the security check would have to be done on the code itself when it is presented by the user, rather than on the code's runtime activity. The rocket science comparison here is particularly apt, since it's an old idea, has been demonstrated in practice, is routine for some uses (rockets take satellites into orbit; Java checks loaded bytecode to make sure it's safe for the VM), yet it is still only practical (so far) in a narrow range of applications. A DSL is much easier, because it can include a very limited set of abstractions and control flow facilities (or no flow control facilities at all.) The same could be said for a lot of kernel work. I would argue that a bytecode verifier is simple compared to many parts of the kernel -- real filesystems and memory management are particularly dense. Getting the complex interactions of mmap, read/write, disk cache, etc correct among all the different types of files and filesystems is far from simple and there have been many actual security flaws in this area in linux (the number is at least an order of magnitude more than flaws in the Java bytecode verifier for instance). It's not like just because there is potential for error it isn't worth doing.
Apparently there aren't kernel developers interested in doing these kinds of things, but I never said there were -- I just said that it would be a lot more fruitful than say getting a slightly better scheduler.
Programs need to take ~6000 cycles between system calls to have only a small 10% overhead just for making the calls, not even to mention the copying of data and setting up fault handlers and such. This is a crazy amount of overhead for some types of programs. And if you can switch a process in 100 cycles versus 2000 then the scheduler doesn't even need to be as fair. Mind giving me and installing an electric engine to put in [my truck] Here you go. It's your truck, you put it in.
You act as if the entire kernel would have to be rewritten and maybe even userspace, but that is not so. They would need to make some changes like being able to do anything from an in-kernel thread that an application can, which is not too terribly far from the current Linux (as opposed to say FreeBSD which would require a *lot* of work to do this). Hell even just start with something simple like inotify (the design of which is absurd) and make it so programs can process events inside the kernel, making it actually be useful (see BPF).