I sometimes add comments like that if the brace is closing a deeply nested block Deeply nested blocks is a sure sign of crap code. Don't document crap code, rewrite it.
Most people using C++/Java/C# end up writing "}//end while" anyway, Pray god I never have to work on code written by these fictitious "most people". Just let me handle their next performance review if such "code" leaks out.
Comments like that are worthless and if they seem to make some sense, then there are worse problems with the code. I guess that does give it some dubious value, it says "An idiot wrote me, please code review me into oblivion".
What kind of idiot actually thinks there is some sort of "sanctity" to tech, or anything tech-related? You didn't read TFA and you're the same kind of idiot as the author. The author nearly hits the mark, but his case would have been stronger if he had used software patents as his example instead of petty copyright violations by users of technology.
"Tech" helped rebuild the ruins of Tokyo after we stopped bombing it. High technology is raising many people out of poverty in India, and I hope my sons are able to do the same sort of thing in their Mother's birthplace - Mindanao (by becoming local jobs providers). So _I_ am an idiot who thinks there's 'some sort of "sanctity" to tech'.
I think you're missing the bigger implication. What if the person writing the article was the same anonymous person editing Wikipedia? I assume that is the case here.
There is absolutely no way Wikipedia can "defend" against abuse like that.
The weak link is the journalist No, the weak link is the amount of trust folks put in Wikipedia. Humans are human and it is human nature to game the system whenever the rewards outweigh the risks.
The GP is a fucking moron if he thinks "throwing an exception" is a cure-all for insecure code. One guy develops a complicated NULL-pointer exploit that's valid in ONE virtual machine, and the GP reflexively supports banning C and C++. Crudely put, but correct. TFA outlines clearly the logic errors in the bytecode interpreter that make this possible. There's a period of time between input validation and usage that can be exploited and it is. Duh. There's an unwise distinct difference between how the input validator and the executor treat invalid input that can be exploited and it is. Duh.
I thought this was going to be something interesting like the 0 page exploit described in Bach's Unix System V Internals book where on certain kinds of hardware, it was possible to read NULL and near NULL pointers without the machine faulting allowing access to kernel data (which worked on my M68K Unix System V box at the time). Instead it's just a sloppily written byte code interpreter bug.
What about the Compiz, Beryl, Fusion fiasco?... Granted, it only lasted, what a couple of months or so You answered your own question. The poster that I responded to was looking at successful forks. What you describe is temporary project confusion that got resolved quickly.
If you cared about your data, you probably wouldn't have gotten involved in the first place. At the time Slashdot picked it up, it wasn't all that good at data integrity in the face of many simultaneous updates, ie. not a real relational database.
They closed off access to their backup utility. You will now have to pay to get it and not get the source code to boot.
Doing relational database backend code is hard work and most lucrative for those who are good at it. Do not expect to be able to support a fork there.
I have no problem with busineses (or individuals like myself) paying for Open Source software. My line is drawn as to whether I have source code or not and if I can support it myself if the original developer support goes away (ie. the current Microsoft Windows XP EOL "crisis").
A talented group of people can produce outstanding software regardless of whether it is open or closed source. From what I've seen throughout my career the most gifted programmers are drawn towards Open Source.
So now that I've defined the problem, the solution is obvious. Fork the backup utility from whatever last version was Open Source and continue on with that. The quickest and best way to tell Sun Micro that They Have Fucked Up(tm) is to produce an Open Source version of the backup utility that works better than whatever crap they're selling their "Enterprise" customers.
Simple, no?
Sun Micro is dense, like any big company. At times they extend a hand to us (as I experienced first hand with XEmacs) and at other times they do not (as I also experienced first hand with XEmacs). A kick in the ass never hurt anyone and IMO would do some good here. Sun Micro isn't evil, just stupid at times. And unlike some people and organizations, if you beat them over the head with a clue stick a few thousand times they will eventually get the message.
Don't get me wrong though, I love postgres. I learned it and mysql before I graduated college. However, once in the working world I learned SQL Server, and it's tools (especially the 2005 SQL management studio) make it far more attractive because it's just plain easier to use. I was introduced to RDBMS programming (Ingres, Omnibase and later Sybase) at work about a decade before I introduced myself to PostgreSQL.
PostgreSQL lends itself well to programming. I wrote the XEmacs Lisp bindings to its pgsql programming interface. Database programming in Lisp really rocks. I don't know how they could make it any easier. A superb programming library (pgsql), conformance to standards (I always used a trade SQL book when I needed a language reference) and good performance (sometimes needing some tuning, but they had builtin tools to help you with that).
Armed unmanned ground vehicle. Nice name for a gun wielding robot.
So I assume these are radio controlled. Two reason I never thought these would work. That's a bad assumption, so I won't bother responding to your conclusions.
None of the robotic prototype weapons I saw while working for a defense contractor in the 1980s were radio controlled.
The GCC/EGCS fork worked because most of the developers went with the EGCS. That fork worked because the GCC mainline was dead *and* the people doing all the real work were the ones who created EGCS. Indeed, what is now called "GCC" is the offspring of EGCS, the orignal GCC was killed.
No comment regarding XFree86/Xorg.
No comment regarding the Emacs/XEmacs fork, except to point out that there was an earlier fork called Epoch made in the version 18 days and that didn't go anywhere. I used it for a time in 1990 and preferred it to straight Emacs 18.
The only other major fork I can think of would be the *BSD forks, Open, Net and Free.
Successful forking is very rare and requires a truly dedicated developer community or large corporate backing to pull it off. Out of the few examples listed one of them was not a fork at all, but a coup and resulted in the death of the parent.
Yes, it's sensationalistic. They will be close sourcing portions of the source, but not the database core itself. The only piece mentioned in TFA is the online backup utility.
I've never understood the reluctance towards PostgreSQL. It's been quite good for quite a long time now.
There were two articles about two different CAPTCHA breakers. In one, the success rate was ~15%, in the other the success rate was ~35%. I've had problems getting a success rate that high on some CAPTCHAs.
Oddly, they're saying a language which is slower for people to write, and considerably more obscure than most languages, is the reason something is done under-budget and quickly? Developmental time is practically irrelevant in the complete software life cycle.
I don't particularly care for static typing (I'm a functional language fanboy), but it is definitely a property of statically typed languages that once you get something to compile, it's much more likely to do something, as opposed to a language like C where you still have a lot of debugging ahead of you when it (probably) doesn't work quite right. Static typing also means you get a lot of correctness checking for free. It's no mistake that in large C language projects like the Linux kernel, the developers are moving towards as much static typing as the C language permits (and developing tools like sparse where it does not).
The point remains, developmental time is irrelevant over the lifetime of a software project. Correctness checking (debugging) and maintenance dominate time costs.
Yeah. The typed I/O stuff was really the pits. It was even more difficult to send arbitrary data across the wire in networked applications (which of course, they all are in C3I - one of Ada's first application domains). Difficult, but not impossible.
Perhaps the best job I ever had was when I was the 900 pound gorilla who vetted commercial Ada compilers. Every so often the boss would come in to my office, drop a package or tape of a commercial Ada compiler on my desk and say, "tell me what you think about this".
I got so frustrated with Verdix Ada at one point because they had potentially the best system, but ignored our (valid) bug reports. After perhaps one beer too many and seeing a remark about VADS on comp.lang.ada, I flamed them. The next day, I got email and a telephone call from a guy at Verdix. After some discussion, I agreed to become a beta tester and if my concerns were addressed to issue a formal public apology on the newsgroup. I did, they did and I did. Unfortunately, the fix was in, the official Unix Ada compiler for the DoD was declared to be Alsys (Ichbiah (Green), Brosgol (Red), duh).
I never met Ichbiah, but I did get to meet Benjamin Brosgol. He participated in Ada training (reeducation sessions) for Software Engineers at the company I worked for. A nice man, but I don't particularly care for the design decisions he makes in language design (and being me, I let him have both barrels - he's remarkably even tempered too).
Alsys was barely usable - the code it produced worked, but even small systems (30k SLOC) took hours to recompile. At one point I was setting up a network test and noticed that one of my embedded message strings was wrong. Rather than doing a painful recompile of the world, I fixed it by editing the binary in Emacs. A couple weeks later, the test was still chugging along (remarkable for Ada stability at the time) and when it was time to give a demo to the highest ranking General in the US Army, the boss lady told me to just leave it running, so I did.
So whatever anyone says about Ada in the 1980s, the view from the trenches was somewhat different. I also have no doubt that the technology probably got quite good in the 1990s. Early adopters always get the rough end of the stick.
Now that I've left I STILL find ADA code running from the 70s. Ada didn't become Ada until 1983. Commercial compilers were still stabilizing five years later. So, if you had working Ada code you had a time machine and you also had a compiler from the future. See (all of the criticisms of Ada were true at the time I wrote it) http://homes.cerias.purdue.edu/~spaf/Yucks/V1/msg00096.html
Now that I'm not forced to work with it, I feel nostalgia sometimes. I built a GNAT RPM for Turbolinux, but I don't they ever distributed it. How is GNAT nowadays?
It's certainly better than a mere right/left, but I have a hard time fitting the 3 clowns left running in the 2 major political parties to any kind of scheme. They all stand for more war, bigger government, higher taxes and less freedom.
Slashdot Mirror
Comments like that are worthless and if they seem to make some sense, then there are worse problems with the code. I guess that does give it some dubious value, it says "An idiot wrote me, please code review me into oblivion".
Andrew Morton can't be nominated - he's a Google employee. He'd be perfect choice if he were eligible.
Google has the patent on toilets used for a server protocol. See http://www.google.com/tisp/index.html
The grinding sequence was done really well by the Southpark guys.
I'd love to see a WoW movie that is up to Blizzard standards. I like the trailers they've made.
Yup. Little known fact: this was added during the review process.
...
<parseOOXML_like_MSOffice2007>
rest of the document goes here
</parseOOXML_like_MSOffice2007>
What 122,000 errors?
Or, if you wanted to criticize the Linux networking penguin
www.fuckingsunblow.su
They asked me, but I turned them down. Better read between the words on that one.
(If) they (had) asked me, but I (would have) turned them down (because I think the whole idea is silly).
There, fixed that for myself.
Yeah, it's unfair that vim (which is a really bad version of vi, give me nvi any day) got representation and we didn't.
"Tech" helped rebuild the ruins of Tokyo after we stopped bombing it. High technology is raising many people out of poverty in India, and I hope my sons are able to do the same sort of thing in their Mother's birthplace - Mindanao (by becoming local jobs providers). So _I_ am an idiot who thinks there's 'some sort of "sanctity" to tech'.
There is absolutely no way Wikipedia can "defend" against abuse like that. The weak link is the journalist No, the weak link is the amount of trust folks put in Wikipedia. Humans are human and it is human nature to game the system whenever the rewards outweigh the risks.
I thought this was going to be something interesting like the 0 page exploit described in Bach's Unix System V Internals book where on certain kinds of hardware, it was possible to read NULL and near NULL pointers without the machine faulting allowing access to kernel data (which worked on my M68K Unix System V box at the time). Instead it's just a sloppily written byte code interpreter bug.
If you cared about your data, you probably wouldn't have gotten involved in the first place. At the time Slashdot picked it up, it wasn't all that good at data integrity in the face of many simultaneous updates, ie. not a real relational database.
They closed off access to their backup utility. You will now have to pay to get it and not get the source code to boot.
Doing relational database backend code is hard work and most lucrative for those who are good at it. Do not expect to be able to support a fork there.
I have no problem with busineses (or individuals like myself) paying for Open Source software. My line is drawn as to whether I have source code or not and if I can support it myself if the original developer support goes away (ie. the current Microsoft Windows XP EOL "crisis").
A talented group of people can produce outstanding software regardless of whether it is open or closed source. From what I've seen throughout my career the most gifted programmers are drawn towards Open Source.
So now that I've defined the problem, the solution is obvious. Fork the backup utility from whatever last version was Open Source and continue on with that. The quickest and best way to tell Sun Micro that They Have Fucked Up(tm) is to produce an Open Source version of the backup utility that works better than whatever crap they're selling their "Enterprise" customers.
Simple, no?
Sun Micro is dense, like any big company. At times they extend a hand to us (as I experienced first hand with XEmacs) and at other times they do not (as I also experienced first hand with XEmacs). A kick in the ass never hurt anyone and IMO would do some good here. Sun Micro isn't evil, just stupid at times. And unlike some people and organizations, if you beat them over the head with a clue stick a few thousand times they will eventually get the message.
PostgreSQL lends itself well to programming. I wrote the XEmacs Lisp bindings to its pgsql programming interface. Database programming in Lisp really rocks. I don't know how they could make it any easier. A superb programming library (pgsql), conformance to standards (I always used a trade SQL book when I needed a language reference) and good performance (sometimes needing some tuning, but they had builtin tools to help you with that).
So I assume these are radio controlled. Two reason I never thought these would work. That's a bad assumption, so I won't bother responding to your conclusions.
None of the robotic prototype weapons I saw while working for a defense contractor in the 1980s were radio controlled.
No comment regarding XFree86/Xorg.
No comment regarding the Emacs/XEmacs fork, except to point out that there was an earlier fork called Epoch made in the version 18 days and that didn't go anywhere. I used it for a time in 1990 and preferred it to straight Emacs 18.
The only other major fork I can think of would be the *BSD forks, Open, Net and Free.
Successful forking is very rare and requires a truly dedicated developer community or large corporate backing to pull it off. Out of the few examples listed one of them was not a fork at all, but a coup and resulted in the death of the parent.
Yes, it's sensationalistic. They will be close sourcing portions of the source, but not the database core itself. The only piece mentioned in TFA is the online backup utility.
I've never understood the reluctance towards PostgreSQL. It's been quite good for quite a long time now.
There were two articles about two different CAPTCHA breakers. In one, the success rate was ~15%, in the other the success rate was ~35%. I've had problems getting a success rate that high on some CAPTCHAs.
That doesn't work for people behind a firewall or other single network entry point.
I don't particularly care for static typing (I'm a functional language fanboy), but it is definitely a property of statically typed languages that once you get something to compile, it's much more likely to do something, as opposed to a language like C where you still have a lot of debugging ahead of you when it (probably) doesn't work quite right. Static typing also means you get a lot of correctness checking for free. It's no mistake that in large C language projects like the Linux kernel, the developers are moving towards as much static typing as the C language permits (and developing tools like sparse where it does not).
The point remains, developmental time is irrelevant over the lifetime of a software project. Correctness checking (debugging) and maintenance dominate time costs.
Yeah. The typed I/O stuff was really the pits. It was even more difficult to send arbitrary data across the wire in networked applications (which of course, they all are in C3I - one of Ada's first application domains). Difficult, but not impossible.
Perhaps the best job I ever had was when I was the 900 pound gorilla who vetted commercial Ada compilers. Every so often the boss would come in to my office, drop a package or tape of a commercial Ada compiler on my desk and say, "tell me what you think about this".
I got so frustrated with Verdix Ada at one point because they had potentially the best system, but ignored our (valid) bug reports. After perhaps one beer too many and seeing a remark about VADS on comp.lang.ada, I flamed them. The next day, I got email and a telephone call from a guy at Verdix. After some discussion, I agreed to become a beta tester and if my concerns were addressed to issue a formal public apology on the newsgroup. I did, they did and I did. Unfortunately, the fix was in, the official Unix Ada compiler for the DoD was declared to be Alsys (Ichbiah (Green), Brosgol (Red), duh).
I never met Ichbiah, but I did get to meet Benjamin Brosgol. He participated in Ada training (reeducation sessions) for Software Engineers at the company I worked for. A nice man, but I don't particularly care for the design decisions he makes in language design (and being me, I let him have both barrels - he's remarkably even tempered too).
Alsys was barely usable - the code it produced worked, but even small systems (30k SLOC) took hours to recompile. At one point I was setting up a network test and noticed that one of my embedded message strings was wrong. Rather than doing a painful recompile of the world, I fixed it by editing the binary in Emacs. A couple weeks later, the test was still chugging along (remarkable for Ada stability at the time) and when it was time to give a demo to the highest ranking General in the US Army, the boss lady told me to just leave it running, so I did.
So whatever anyone says about Ada in the 1980s, the view from the trenches was somewhat different. I also have no doubt that the technology probably got quite good in the 1990s. Early adopters always get the rough end of the stick.
Now that I'm not forced to work with it, I feel nostalgia sometimes. I built a GNAT RPM for Turbolinux, but I don't they ever distributed it. How is GNAT nowadays?
You insensitive clod! I never greet people that way!
I like the Pournelle Axes describing a political spectrum - http://www.baen.com/chapters/axes.htm
It's certainly better than a mere right/left, but I have a hard time fitting the 3 clowns left running in the 2 major political parties to any kind of scheme. They all stand for more war, bigger government, higher taxes and less freedom.
Of course a matter of taste is involved. My primary exception to that rule is World of Warcraft which many people despise here. There are others ...
I prefer handhelds and maybe that will explain some of it.