I have heard a lot of (fairly uninformed) criticism of Germany's decision to outlaw the Scientology sect.
However, with the Fishman affidavit, the whole case concerning Karin Spaink (see http://www.xs4all.nl/~kspaink/fishman/home.html), and now this I feel strengthened in my support for the decision of the German government to outlaw this sect.
Regrettably it doesn't work like that in the US. We gave them the tax-exempt status of "church" instead.
Records showing someone whose moment of decease can in fact be said to pre-date the record in the records can be amended at the time the discrepancy between recorded circumstances and the record became a matter of record.
In fact no revision of the recorded procedures of keeping record needs to be recorded, and proposals for a Necromancy division should, for the time being at least, be recorded as "filed".
to make reality conform to the records. Purely as an administrative procedure you see. Off the record of course, but much quicker than setting about altering the records.
After all... we can't have inaccurate records now, can we? That would be the road to chaos! And think of the savings. We wouldn't have to go on record recording changes to the records, and who benefit from such a record?
Why not set up an adminstrative comittee suitably empowered to, and responsible for, maintaining the integrity of the records? How about that? It would solve this little problem in record time!
Lifting capacity: 15 lbs. (according to manufacturer).
Assuming you want a camera and a video transmitter on board (say about 2 lbs together), that should still allow you a payload of 6 lbs. and a comfortable safety margin. By the way, any idea what 2 ounces of plastic explosive can do? It can comfortably demolish a car.
Well... I'm no expert, but I'd take a $2100 helicopter kit any time over a not-so-smart bomb. Doesn't show up on passenger lists, won't be picked up at the border for having an Arabic accent (or speaking no English at all), being nervous or zombie-like. No need to house and babysit a volatile human being. Much easier to get to the precise spot you want to target despite police cordons. Can dash in if needed. Won't blab if caught or shot down, and will allow me to retain control of events.
I'm afraid that people who are able to finance flying lessons + condo's for 6 young men for a few months will also be able to finance a $2100 helicopter kit. Plus camera and payload.
Sorry to go on about this, but it's got me a bit worried.
There is nothing intrinsically "terrorist" or "law enforcement" about weapons... or armed robots. A weapon can point both both ways.
I'm afraid that the article makes perfect sense. In its urgency to develop new toys for the "War against Terror", the US are developing smart and capable robots developed that would be ideal tools for terrorists.
Take for example those mini helicopters with built-in camera and video link... load them up with a few pounds of plastic explosive and steer them where you want. A busy train station? No problem. A main street or a shopping mall? Can be done. The Superbowl stadium? Feasible. A Small foot patrol in Iraq? Easy!
Then when they are surrounded by enough victims you press the button in the luxury of a safe hideout a mile or so away and generate instant headlines. Hard to prove against you too (if you don't keep the control console around and don't sign your name on the receipt for tAfraid that someone will notice and shoot your drone down before it's in position? Use three!
And all it takes is a small inexpensive mini flying machine (for when you are still in sight of your objective) or a more expensive one (and a relatively expensive video link), some explosive, and some duct tape. Ah yes... and perhaps some nails.
And the best thing for your average terrorist is: his tools are now being developed for him... all he has to do is wait and steal one at the appropriate time. But what am I saying? Steal? Just use a mail order catalogue or Ebay. Great eh?
The fact that MS Windows applications aren't perfect does not detract from the the impression that poorly designed GUIs (both in applications and in the OS) are holding Linux back.
At work I have used MS Outlook for 5 years now, and it hasn't crashed on me as far as I can remember. But then I only use it for email and for keeping appointments. The servers (also Windows) did go down once or twice in that period. A nuisance to be sure, but not crippling.
If it makes you feel better, I consider MS Outlook's GUI opaque and not very well designed. This does not change the fact that using the GUI I can reliably do simple things with it, without having to remember any commands, and that I can safely ignore all the rest of its functionality.
My intention is not to talk down Linux, on the contrary. What I hope to achieve is to make people understand the importance of good and above all largely standardised GUIs for standard productivity software in furthering the uptake of Linux. That's the focus of this thread: as in "We gave people dozens of shiny Linux distributions, and what do you know... they won't switch. How come?".
Counter to Linux hobbyists, for many of whom I suspect that *using* Linux is a goal in itself, I think that the average end-user uses his computer to actually do something. Such users simply have no wish, and no patience, to invest heavily in learning Linux or Linux/Unix specific applications (All those CLI-based tools and such idiosyncratic control-sequence rich programs as VI and Emacs come to mind)... and they shouldn't have to.
In this respect I consider that Linus Torwald's opinion that the Linux kernel is no longer where the main action is when it comes to acceptance or non-acceptance of Linux insightful. The Kernel is good enough (although it still needs work in the area of user-responsiveness under heavy background loads), and end-users have little or nothing to do with the Kernel in any event. It's there, but you shouldn't notice it and it should just work. It's the Windows manager (KDE or Gnome), the GUI to the OS, and the applications that determine Linux uptake now.
At this stage I might add that the tone of the responses on a typical Linux forum might put people off. In this respect I believe the rant by a certain anonymous coward in this thread which basically states: "we-don't-work-for-you-and-we-don't-care-if-you-use-our-software-and-you-should -just-learn-how-it-all-works", nicely illustrates the mentality of certain members of the Linux community. It doesn't take all that many of such responses to drive someone off who is posting uninformed (but to the poster important and perhaps puzzling) questions and perhaps complaints in the help section of a forum.
I know I won't make myself popular here, but nevertheless. I think it has to be said.
I believe that Linux being free has nothing whatsoever to do with its value perception.
Instead I believe that people, and to some extent correctly, still equate Linux with "something for geeks, not end-users" because of:
- the generally poor standard of GUI's on Linux itself and Linux software
- the generally dismissive attitude of Linux users / software developers for a nice polished GUI with all the details taken care of.
There... I've said it. So flame me.
Ordinary users simply do _not_ want something that forces them to go to the command line for system maintenance. Neither do they want to have to edit configuration files, let alone scripts. It has taken Linux distributions years to come up with something as sophisticated as YAST (for SuSE Linux) and KDE Control center, and especially KDE still doesn't provide a reliable one-stop solution to detect and install my inkjet printer. I have to go to CUPS for that. In a word... it's less simple than MS Windows (unless you already know what you should be doing because you did it before and kept notes).
I have seen threads with expostulations about how great command line oriented programs are, and I agree... for some programs that are oriented towards batch processing, for repetitive jobs, and for software that I write myself for my own use. (When I write software for my own personal use, I never write GUIs. Command-line, control files, and file in, file out. If a GUI is needed, someone else can do that.)
But for other people's programs, and for programs I don't use every day I want to be prompted and guided... by a GUI... with tooltips and a smoothly functioning and fairly complete Help function. The very last think I want is to be obliged to read a manual and remember commands for some fink of a program before I use it. I believe I have a typical end-user mentality in this respect.
And did I mention that as an end-user I really do _not_ want to see every program sporting its own GUI layout either? I don't care a fig about what some programmer thinks is good way to organise his GUI. I want my GUI to be *standardised* (at least the toolbar) so that it's somewhat familiar as soon as the application starts. Copy-paste should of course be supported, and don't you dare to let it default to any other key combination than C for copy and V for paste, and a print option (if applicable at all) right where I expect it... under the menu (which has to be the leftmost menu) somewhere 3/4 down the list.). Well... I might be able to cope with a standard GUI layout under Linux that's different from Windows, but no more than one.
And then the graphics itself... ouch. I really *hate* GTK-based programs. They look somewhat like the Windows programs I'm used to, but the widgets work differently. I find them clunky. Ugly and clunky. Again, I couldn't care less what some programming community thinks of them. I don't want them. Take the typical GTK file menu for one thing. An abortion! And what's more, I won't have them unless there is no alternative.
As an illustration, take for example AviDemux (see here: http://fixounet.free.fr/avidemux/). It comes in two flavours: with a GTK+ interface and with a QT4 interface. I tried the GTK+ flavour first and disliked it. The QT4 version on the other hand was acceptable. It didn't irritate.
The good news is that this nicely illustrates the difference between what in the context of "Git" (the version control software) is called: the plumbing (the guts) and the porcelain (the superficial layer that comprises the GUI). A well-designed GUI can be rendered in either GTK+ or QT4, and it should have absolutely no impact on the plumbing.
I agree that one can see a receding horizon effect in the sense that problems that were once considered to hold the key to providing AI (something that mimics the capabilities of a human mind (or body)) were later found not to provide much of an advance in that direction after all.
I submit that there is a fairly sharp criterion for detecting "real" AI: the Turing test. For a robotic equivalent of a human body this might be the tie-your-own-shoelaces test. Of course lots of subjects have emerged that could be studied in isolation and which yielded useful and definite knowledge, but were originally lumped under "AI" because people thought might help them on the way to create a "real" AI.
To me this mostly illustrates the fallacy of thinking: "If we could only solve this problem, we would have AI". So far it has turned out to improve our insight in what the Human mind isn't, and in parts (neural networks) how parts of it (probably) work. Both impressive achievements, but nothing in the way of constructing an AI that can e.g. pass the Turing test or tie its shoelaces. But those specialist subjects tend to lack the hype that surrounds "AI".
In this vein I think it's either an act of total irresponsibility to sell, what basically amounts to a wild-ass guess, as a "prediction" of the type the article mentions, or a deliberate attempt to use the "AI" hype with the sole purpose of obtaining funding.
Has it occurred to you that all of us already work, to some extent, at the direction of computers? Think of the tens of thousands of pilots and flight attendants... what city they sleep in, and who they work with, is dictated by a computer which makes computations which cannot fit inside the human mind. An airline could not long survive without automated scheduling.
Next consider the stock market. Many trades are now automated, meaning, computers are deciding which companies have how much money.[...]
That's enough. Err... frankly your reply has given me pause. Seriously. It betrays a wealth of misunderstanding about AI and computing in general, and I have been wondering if I my reply should be a sarcastic one or just an explanatory one. Given the nature and the depth of the misunerstanding displayed here, I have settled on an explanatory one.
What you call "Automated scheduling" is part of a branch of applied mathematics known as "Operations Research". Basically it's the art and science of formulating a practical, real-world problem (such as air-crew scheduling, devising FedEx routes, loading aircraft, routing goods flows through transport networks as efficiently as possible, finding optimal stock portfolios, finding optimal ways of running an oil refinery, etc. etc.) into a mathematical problem, (usually a so-called "optimisation problem; see http://en.wikipedia.org/wiki/Category:Optimization_algorithms) and then devising appropriate solution algorithms that can be executed by a computer (usually a digital one) to give exact or approximate optimal solutions to said problem. See also: http://en.wikipedia.org/wiki/Operations_research
Such problems can be quite large... e.g. with thousands of variables and tens of thousands of constraints. Now I'm confident that you would be quite unable to solve a 2x2 LP problem (i.e. a Linear Programming Problem, one of the most basic Operations research problems) in your head, or a 3x3 problem using pen and paper. Any PC can run a program that solves such problems in microseconds. This however has nothing to do with the question of whether solving an LP problem is to be classified as AI or not. As a matter of fact, solving LP problems is not, and has never been, considered part of AI. The same holds for all the other OR problems I mentioned.
Now it turns out that many of the problems I mentioned don't have what are known as "efficient" solution algorithms. Meaning we don't know of any exact solution algorithm that has polynomial run-time on a digital computer; instead all known algorithms have *exponential* run time on a digital computer. In such cases one resorts to what are known as "heuristics" (see http://en.wikipedia.org/wiki/Heuristics#Computer_science ), being algorithms that aren't guaranteed to find an optimal solution, but which sometimes *can* be guaranteed to come within say p% of the optimum, or at least to come up with a fairly decent solution. Some of the heuristics used, e.g. what are known as "branch-and-bound" algorithms (see http://en.wikipedia.org/wiki/Branch_and_bound) are based on questions that were (also) encountered or raised in the study of AI.
The important thing to note is that in general this has nothing whatsoever to do with Artificial Intelligence per se. Artificial Intelligence (AI) research on the other hand deals with problems like: "How can we induce computers to exhibit behaviour mimicking the Human Mind, or the Human body" (see: http://en.wikipedia.org/wiki/Artificial_intelligence))
Note the lack of overlap between Operations Research (OR) and Artificial Intelligence (AI) problems. The m
For over 40 years, the field of AI has been *littered* with predictions of the type: "We will be able to mimic Human levels of xxx" (substitute for XXX any of the following: contextual understanding, reasoning, speech, vision, non-clumsy motoric ability).
So far _not one_ of those claims has come true, with the possible exception of the the much-vaunted "robotic snake".
So... I'd say: less claims, fewer predictions, and more work. Let me know when you've got anything worthwhile to show.
Not to be outdone by forecasters, I have a forecast of my own to make: before the term is us it will transpire out that all this fanfare and this announcement were only ever meant as means to attract research grants.
No, let's encourage more people to be techies, engineers, and scientists, and pay them better than dumbass MBAs for a change.
I'd love it if that were somehow possible. I really mean that.
However... I do see a few probl... err... I mean of course "Opportunities" here.
The first one being the opportunity to convince management in the US to pay engineers and scientists more and/or MBA's less.
The second one would be to convince them to stop seeing the engineering and R&D departments as regrettable cost centers to be outsourced and/or off-shored at the first opportunity.
The third opportunity would be to convince industry to offer Ph.D's opportunities (and to some extent academic entry-level positions) that make it less of a financial risk to do a Ph.D.
Prospects for Ph.D's (depending on discipline of course) can be so awful that you have to basically tell students: "Don't do a Ph.D. unless you (a) really derive fulfillment from doing research / teaching even if you're paid half to 1/3 of what you'd get in industry and (b) you are in the top 5% of your class, or you won't be able to get tenured".
And let's take away China's "Most Favored" trading status, if they keep up this shit. Why not? I do not feel obligated to help other nations that then turn around and dump on us.
Well... industrial espionage is part of doing business. Between companies as much as between countries. Besides, trade is a two-way street. It's not as if the US are providing China with development aid. The US are benefiting from cheap Chinese products too. Have you ever considered what the impact on the US would be if there were to be say, 30% import tariffs on Chinese goods?
All those PC's, printers, T-shirts, hand tools, shoes, toys, and what not? First you'd kick off a vicious round of inflation if you did... plus you'd be seriously hurting the bottom line of such all-American companies that have off-shored their manufactoring operations to China (just think of HP).
Generally speaking, you'd saddle lots of US companies with higher costs which would make them vulnerable in the current economic downturn *and* make them less competitive with e.g. EU-based companies.
Sure... it would hurt China. They might even have riots. But it would hurt the US too. Very much so I'd say. So let's just be very sure about the cost-benefit ratio of such measures before we seriously propose them, ok? Like it or not, the US is as much networked into the global economy as China, the EU, and OPEC.
It's not to say that the US can't rescind China's "most favoured nation" state. Of course it can! The question is: what are the costs and what are the benefits. And I submit that the costs just might be a bit steep for the satisfaction of making our displeasure about industrial espionage known.
Honestly, industrial espionage in the US has been proven to be committed by: France (NATO ally), Israel (special ally) , Russia (ex-enemy), China (competitor).
Nothing new there. Besides, I'd be amazed if e.g. India, Pakistan, Brazil, South Korea, Japan, South Africa, and Iran weren't also active (or trying to be active) in this field.
Why then do we hear often about Chinese espionage? Is it just that Chinese espionage makes good headlines?
Well... perhaps it has something to do with the fact that there are so many (very good) ethnically Chinese engineers and scientists in the US, in all walks of life. Due to do Americans not being interested in an arduous career in Engineering or the Sciences when they can instead aim at Management, Legal services, or brokerage I'm told. Well, admittedly the Chinese government is quite organised about industrial espionage, and it's easier to get a rapport with an ethnic countryman than with some foreigner.
So... if we assume a fixed promillage of the population open to espionage proposals, we must expect Chinese to be over-represented.
Besides which... it's not as if the US doesn't commit industrial espionage of itself (primarily in the EU; see e.g. http://www.guardian.co.uk/world/2000/mar/31/ianblack).
Lets just save our righteous indignation for a more worthy cause and simply shore up security on projects and firms that are attractive targets, shall we?
I don't think this would be at all reasonable. Boycotting Trend Micro software is something I'd agree with though.
However, much as I like Open Source Software in general, I consider it perfectly OK if people decide to use commercial, closed-source, anti-virus software. I would urge them to (re)consider using such software in favour of OSS, but if they wish, for whatever reason, to spend their money on closed-source anti-virus software, then best of luck to them (and the producers of closed-source AV software).
What galls me in this case is the unfair way in which Trend Micro uses a blindingly obvious patent they somehow got their hands on to squeeze an OSS competitor out of the market. The patent, basically the idea of having a virus scanner on gateway servers to a network that scans incoming files as they are being transmitted, is of course trivial.
Why?
The idea that in order to prevent infected files from entering a network, you can do the checks "at the border", i.e. in the gateway server, is about as obvious as the idea of keeping a place dry by having a roof and 4 walls. Since the incoming files aren't stored on the gateway server but immediately forwarded, the only thing you can do is to stream the incoming file through an AV scanner. Patenting an "invention" like that is of course only possible in the US.
Unfortunately the law says that even such patents have force, so an unscrupulous commercial AV vendor (Trend Micro) can use it to sue people for doing this.
That's why I'd support a boycott of Trend Micro. Not because they're closed-source vendors, but because they behave like thugs.
No, it is not. It is simply faced with a single-minded regulator which takes its job seriously and isn't fazed by the fact that Microsoft is a brazen repeat-offender.
We don't yell at GM for not making its On-star open to everyone.
GM does not have an 80% market share in the car market. Microsoft does have such a market share in the desktop OS market. That's a big difference.
What Microsoft is currently doing with OOXML is a thoroughly unethical (paying companies PR contributions to vote in favour of OOXML, offering small countries rebates to vote in favour of OOCML, and suddenly stuffing ISO standards committees with pro-microsoft members who never before had an interest in ISO procedures in their lives) attempt to continue its lock-in, which regrettably seems to have a chance or working. (see e.g. http://www.consortiuminfo.org/standardsblog/article.php?story=20080208082501776 and
http://www.theregister.co.uk/2008/02/08/ooxml_eu_probe_iso/ )
I see absolutely nothing to salute Microsoft about regarding its determination to disregard fair-competition and anti-trust regulations and I support the EU in this matter. Why don't we see any US regulators step up to the plate?
Sorry, but this again highlights the bad things that happen when rank amateurs start reading and interpreting legal texts.
Assuming for a moment that the link you provide does indeed contain the law that governs this particular case, further reading should have shown you this:
(3) Termination of the grant may be effected at any time during a period of five years beginning at the end of thirty-five years from the date of execution of the grant; or, if the grant covers the right of publication of the work, the period begins at the end of thirty-five years from the date of publication of the work under the grant or at the end of forty years from the date of execution of the grant, whichever term ends earlier.
As I read it: if you grant someone a license on copyright that you own then you have to wait 35 years before you get a 5-year period during which you may revoke your earlier grant.
Now I'm not completely sure if that's how the law should be interpreted, but it clearly shows the ill-advisedness of trying to interpret the law as amateurs. Instead I suggest you seek an informed opinion such as e.g. Groklaw (http://www.groklaw.net/article.php?story=2006062204552163)
With the word "threatening" I referred to the essence of your post, which is to deny that Trend Micro accused ClamAV of patent infringement. It did. Denial of the main issue on a mere point of phrasing is not the way an honest debate is conducted, let alone with the language you seem believe is appropriate for you to use.
Apparently I have to be a little more precise to deny you any wiggle room that might allow you to use a loose phrase on my part as a cop-out. Well, here goes.
The investigation is based on a complaint filed by Trend Micro Incorporated of Cupertino, CA, on November 21, 2007. The complaint alleges violations of section 337 of the Tariff Act of 1930 in the importation into the United States of certain systems for detecting and removing viruses and worms, components thereof, and products containing same that infringe a patent owned by Trend Micro. The complainant requests that the ITC issue an exclusion order and cease and desist orders.
See the highlighted bits? Just to make things explicit for you: they show that Trend Micro really *did* accuse Barracuda of patent infringement. It did this by filing a complaint with the United States International Trace Commissions (USITC). Notwithstanding the fact that the USITC is not a district court, this clearly shows that Groklaw's report is correct, and your off-hand opinion is wrong.
Having settled that, the ZDnet article notes that Trend Micro had sent Barracuda a lengthy series of legal correspondence pointing out that in their view Barracude either had to pay them or stop using the OSS program ClamAV. Now the only ground they could have claimed that on is by pointing out that Barracuda used CLamAV which, allegedly, infringes on Trend Micro's patent. Since the end user is responsible for patent infringement of OSS software they user, this in effect means that Trend Micro accused Barracuda of patent infringement. So the ZNnet article I cited shows the same thing, namely your claim that Trend Micro did not accuse Barracude of patent infringement is wrong and Groklaw's representation is right albeit not as authoritativelty as the press release from the USITC.
Since 2006, Barracuda Networks has been receiving communications from Trend Micro's legal team requesting Barracuda either pay licence fees when using ClamAV, or stop incorporating the software into its products, according to Barracuda's chief executive and president, Dean Drako.
I don't know what you consider threats then, but if company X tells you to cough up or stop using an OS package that they claim infringes on their patents, *I* would consider that a threat.
I really don't see in what sense Groklaw supposedly made a mistake. In fact I think Groklaw's presentation of fact is correct. Unless you can point to solid evidence that shows otherwise I'll just have to assume that you misread the material you saw.
Well, nice mr. Niro probably wants to know the identity of the anonymous blogger to have a chance to have an intimate legal conversation with him. Lawyer talking shop to lawyer as it where, in a private setting.
I really don't see the problem, do you? I'm certain it will all be legal, so there's nothing to worry about. No. Really.
Groklaw indeed carries a bias in favour of Open Source. It is completely open and up-front about it.
This bias however has nothing whatsoever to do with:
- the quality of their editorial opinions (as opposed to Slashdot they actuall *have* an editorial opinion, counter to Slashdot they are actually knowledgeable about legal issues, counter to 99% of Slashdot they actually read the stuff they write about. Besides, I haven't seen them shown wrong yet, mostly the opposite.)
- the quality of their reporting is quite impeccable (they show you where they get their data from, they tell you what they base their opinions on)
Lest you make a serious logical mistake, differentiate between your scepticism regarding their sources and their actual knowledge(which have so far proved impeccable) and their opinions (which you may be sceptical about but which they clearly highlight).
Better a knowledgeable site that has a bias (which it is honest and up-front about) than a whole stampeding herd of ignoramuses with a 10-minute attention span.
Nowhere did the article say that there was a worry of Geiger counters being triggered by exhaust gases. Geiger counters are not triggered by exhaust gases. No matter how poorly built.
The article did mention some concerns from DOH officials about the potential for false alarms. Requiring regulation for geiger counters or air quality monitoring equipment is a bone-headed, inappropriate, and totally disproportionate response to potential problems.
It seems as if the DOH has too much time on its hands. That's what you get when you create a whacking big government organisation: the whackiest ideas sudenly get support within it and are then solemnly passed off to external organisations as: "This is what we advise you to do because there *might* conceivably be drawbacks if you don't"
This is a legal question, and since Slashdot readers tend to have no legal knowledge (let alone qualifications) it's best to look at sites that deal with legal issues.
The first one to check is of course Groklaw, which provides the following answer (see http://www.groklaw.net/article.php?story=2006062204552163): "No. One can't retroactively revoke licenses previously granted, unless the license terms allow you to do so. The most you can do is stop granting new licenses."
OK, and we could stop quoting here---the rest of this post was just more of the condescending attitude.
Well... first off we'll make allowances, this being Slashdot, but *sometimes* it helps to read the opening post. Don't let me talk you into anything unnatural for you, but I'd just like to put it forward. As a suggestion you know? For you to err... think about.
In this case the opening post gives some interesting clues as to the problem the poster is facing. Read with me if you will:
"Having just recently taken a new job, I find myself confronted with an enormous pile of existing, unfamiliar code written for a (somewhat) unfamiliar platform -- and an implicit expectation that I'll grok it all Real Soon Now.
This explicitly tells the interested reader two things:
- the poster is confronted with a large unfamiliar code base
- he isn't even familiar with the target platform
- his job requires is that he has to get this codebase under control pdq
- he's brand new new to his job
Those who, reading between the lines, infer that he hasn't got any proper documentation for said codebase can get bonus points.
The poster further writes:
Simply firing up an editor and reading through it has proven unequal to the task.
This tells the attentive reader one more thing. Just reading the code wasn't helpful. That's what the man said. So... printing the stuff out and playing "Little Picasso" with coloured marker pens won't be much of a help either, ok? This isn't about regaling people with unverifiable anecdotes of your personal programming highlights, it's about providing the author with sound and practical suggestions that he can use in his job.
The reply implies that it's impossible to understand the code without the full shampoo treatment (version control, tracing, profiling, instrumenting of memory allocation).
Even close reading of my previous post fails to reveal any claims on my part to the effect that e.g. version control or instrumenting memory allocations are crucial to understanding the code base. They are simply sensible precautions any software engineer would take before
(a) karking around with a huge code-base he can't make head or tail of, and
(b) assuming that whatever code he's been handed doesn't contain a lot of goofy mistakes that will come to bite him as soon as he changes anything.
This guy is going to be *responsible* for that code-base. For his *job*. His *brand new* job. And he's asking on *Slashdot* for tips on how to tackle a new code-base. Well... pardon me for leaping to the conclusion that he needs some help here and that he isn't too experienced in dealing with real-world software maintenance. So let's just forget to mention that he should establish a baseline of the code-base he has before touching it, shall we? Might be good for a couple of laughs when he finds out and can't revert his changes. Tee-hee-hee.
Oh yes, and when would you like him to find out about any memory allocation problems? Right now, or when he's under a deadline to make modifications to the code-base that may play merry hell with whatever allocations that have been hacked into working? And as said... reading code isn't going to clue you up much regarding any memory allocation problems. It it were, then we wouldn't *need* code instrumenters to check for memory allocation problems, ok?
As to tracing and profiling. Think you can infer the execution path for the normal case of a non-trivial program you know nothing about by reading it??? Is that what you're saying? How do you know that the top 20% of the code doesn't deal with test-cases and verification of whatever input that that program takes, and was left in because it was considered handy to have that right next to the production code?
Well... some good points, and some I'd say are too detailed at this point.
I totally agree with point (1). I forgot to mention it since I assumed (always a bad thing) that the author actually could compile and run the thing. An important point to keep in mind. Thanks for bringing it up.
Points (2)-(5) however all come after you've understood the basic structure of your code base.
Next, I'd say that a fairly junior software engineer trying to tackle a large unknown code-base without proper tools is doomed to failure no matter what. So the step from "If you're in a rush" and "You are in a paid job and expected to deliver predictable results." to "forget about tools you're not familiar with and just dive in" is an exercise in self-delusion and a recipe for disaster. Nothing less. It's like someone rushing out of the house and sprinting for work because they don't know where they put the car keys or their bus ticket and feel they are too much in a rush to search for them.
Besides, producing automated documentation is a good way to communicate. The tool communicates the structure of the code-base to you, and you can use e,g, the call-graphs to (efficiently) communicate the complexity (or otherwise) of the code-base to your supervisor. It also communicates to him how you are approaching the problem, which is likely to be a plus.
Now suppose the codebase is really difficult. A competent software engineer is, like any other kind of engineer, co-responsible for making actual and potential trouble spots *visible* to management. Preferably before they explode. Although it's popular wisdom to despise Management, if you, the hands-on person, don't tell Management of the problems, you ensure that they're driving blind. You rob them of the chance do do anything about it before the problem becomes so acute that even they'll have to notice. They will recognise it if you do and keep it in mind when they have to assess you. Depend on it. Besides, you just happen to be the only one who can tell them, and you fail in your responsability if you don't. Part of a software engineer's job is to *communicate*. Now you can't give your supervisor any honest estimate of how well you have the new code base under control before you get to know it. And tools really really help you save time and allow you get a much better overview.
Communication works both ways. If, with all the tools you use, you are unable to understand the code-base, you lack one or perhaps two elements that distinguishes a basic software engineer from a good or even a great one. Talent and experience. And you should be honest with yourself and your supervisor about that too. If the job really is too hard for you, have the guts to own up before you mess up and thereby save yourself and your company a lot of trouble. And believe me... there are lots and lots of good jobs in software development / maintenance that can be done without a surfeit of either. Such is the power of engineering.
Now Doxygen (or similar tools) may be unfamiliar to the author, but such tools really work. Besides, I've seen students download, understand, and use Doxygen in less than 1 hour after they were told about it.
An interesting post, even if it's absolute tosh. No-one in his right mind tackles a new code-base of any size or complexity with nothing but a printout. Not if he's expected to understand how it works and/or maintain it in a responsible way.
In fact, it nicely highlights the difference between "software engineers" and "code monkeys". Code monkeys just dive in; they never pause to think. In fact... they tend to avoid thinking. It's not their strong point. After all... they're paid to code, right? Not to think. Software engineers on the other hand, look before they leap and spot the places where they need to pay attention first. And they're systematic about it.
In fact, a software engineer will happily spend a day or two putting the right tools in place, *including* a full backup and a proper version management system for when he's going to have to touch anything.
The first thing you want to know about a new code base (after you find out what it's supposed to be doing) is its structure. Tools like Doxygen (see previous posts) show you that structure *far* quicker and *far* more reliably than any amount of dumb code-browsing can. And besides... once you do it, you've got that documentation stashed away securely instead of milling around incoherently in your head (you'll have completely forgotten most of what you read by next month) or on disorganised pieces of note paper.
The second thing is to figure out if it calls any "large" functionalities like subroutine libraries or even stand-alone programs like databases, let alone if it makes operating system calls. The call-tree will give you an excellent view, and the linker files can complete the picture. You wouldn't be the first maintenance programmer who found out after months that his application critically depends on some other application he wasn't told about.
The third thing is to see where your code does dirty things. Let the compiler help you. Just compile your application with warnings on and have a look at what the compiler comes up with. You might be surprised (and horrified). Then compile with the settings used by your predecessor and check that your executable is bit-for-bit identical to what's running (you wouldn't be the first sucker who's given a slightly-off code base).
If performance is at all important, then running the whole thing for a night on a standard case under a good profiler will also tells you lots of important things. Starting with where your code spends its time, where it allocated memory and how much, and where the heavily-used bits of code are. All neatly written down in the profiler logs.
Finally, run your application with a tool to detect memory management errors the first chance you get. Useful tools are Valgrind (in a Linux environment), Purify (expensive, but probably worth it) under Windows, and sundry proprietary utilities under Unix. Just about 90% of the errors made in C programs come from memory management problems, and half of them don't show up except through memory leakage and overwritten variables (or stacks.. or buffers.. or whatever). You'll need all the help you can get here, and as far as these errors are concerned, dumb code browsing is useless. Just keep your head when looking at reports from such tools... they can throw up false positives. Ask around on a forum with specific questions if you're allowed, or ask your supervisor. After all... you showed due dilligence.
When you know all that (if you have the tools in place, all of this can be done within 1 day + 1 overnight run + 1 hour reading the profiler output), go ahead and trace through the code in a debugger. You'll be in a *far* better position to judge what you should be reading.
Slashdot Mirror
The scientology cult isn't outlawed in Germany but just not tax exeampt and not recognised as a religion, just as you say. I found this link: http://home.snafu.de/tilman/krasel/germany/government.html
However, with the Fishman affidavit, the whole case concerning Karin Spaink (see http://www.xs4all.nl/~kspaink/fishman/home.html), and now this I feel strengthened in my support for the decision of the German government to outlaw this sect.
Regrettably it doesn't work like that in the US. We gave them the tax-exempt status of "church" instead.
Records showing someone whose moment of decease can in fact be said to pre-date the record in the records can be amended at the time the discrepancy between recorded circumstances and the record became a matter of record.
In fact no revision of the recorded procedures of keeping record needs to be recorded, and proposals for a Necromancy division should, for the time being at least, be recorded as "filed".
After all ... we can't have inaccurate records now, can we? That would be the road to chaos! And think of the savings. We wouldn't have to go on record recording changes to the records, and who benefit from such a record?
Why not set up an adminstrative comittee suitably empowered to, and responsible for, maintaining the integrity of the records? How about that? It would solve this little problem in record time!
Price: $2099.95;
Mail-order from heli-world (see http://www.heli-world.com/)
Lifting capacity: 15 lbs. (according to manufacturer).
Assuming you want a camera and a video transmitter on board (say about 2 lbs together), that should still allow you a payload of 6 lbs. and a comfortable safety margin. By the way, any idea what 2 ounces of plastic explosive can do? It can comfortably demolish a car.
Well ... I'm no expert, but I'd take a $2100 helicopter kit any time over a not-so-smart bomb. Doesn't show up on passenger lists, won't be picked up at the border for having an Arabic accent (or speaking no English at all), being nervous or zombie-like. No need to house and babysit a volatile human being. Much easier to get to the precise spot you want to target despite police cordons. Can dash in if needed. Won't blab if caught or shot down, and will allow me to retain control of events.
I'm afraid that people who are able to finance flying lessons + condo's for 6 young men for a few months will also be able to finance a $2100 helicopter kit. Plus camera and payload.
Sorry to go on about this, but it's got me a bit worried.
I'm afraid that the article makes perfect sense. In its urgency to develop new toys for the "War against Terror", the US are developing smart and capable robots developed that would be ideal tools for terrorists.
Take for example those mini helicopters with built-in camera and video link ... load them up with a few pounds of plastic explosive and steer them where you want. A busy train station? No problem. A main street or a shopping mall? Can be done. The Superbowl stadium? Feasible. A Small foot patrol in Iraq? Easy!
Then when they are surrounded by enough victims you press the button in the luxury of a safe hideout a mile or so away and generate instant headlines. Hard to prove against you too (if you don't keep the control console around and don't sign your name on the receipt for tAfraid that someone will notice and shoot your drone down before it's in position? Use three!
And all it takes is a small inexpensive mini flying machine (for when you are still in sight of your objective) or a more expensive one (and a relatively expensive video link), some explosive, and some duct tape. Ah yes ... and perhaps some nails.
And the best thing for your average terrorist is: his tools are now being developed for him ... all he has to do is wait and steal one at the appropriate time. But what am I saying? Steal? Just use a mail order catalogue or Ebay. Great eh?
At work I have used MS Outlook for 5 years now, and it hasn't crashed on me as far as I can remember. But then I only use it for email and for keeping appointments. The servers (also Windows) did go down once or twice in that period. A nuisance to be sure, but not crippling.
If it makes you feel better, I consider MS Outlook's GUI opaque and not very well designed. This does not change the fact that using the GUI I can reliably do simple things with it, without having to remember any commands, and that I can safely ignore all the rest of its functionality.
My intention is not to talk down Linux, on the contrary. What I hope to achieve is to make people understand the importance of good and above all largely standardised GUIs for standard productivity software in furthering the uptake of Linux. That's the focus of this thread: as in "We gave people dozens of shiny Linux distributions, and what do you know ... they won't switch. How come?".
Counter to Linux hobbyists, for many of whom I suspect that *using* Linux is a goal in itself, I think that the average end-user uses his computer to actually do something. Such users simply have no wish, and no patience, to invest heavily in learning Linux or Linux/Unix specific applications (All those CLI-based tools and such idiosyncratic control-sequence rich programs as VI and Emacs come to mind) ... and they shouldn't have to.
In this respect I consider that Linus Torwald's opinion that the Linux kernel is no longer where the main action is when it comes to acceptance or non-acceptance of Linux insightful. The Kernel is good enough (although it still needs work in the area of user-responsiveness under heavy background loads), and end-users have little or nothing to do with the Kernel in any event. It's there, but you shouldn't notice it and it should just work. It's the Windows manager (KDE or Gnome), the GUI to the OS, and the applications that determine Linux uptake now.
At this stage I might add that the tone of the responses on a typical Linux forum might put people off. In this respect I believe the rant by a certain anonymous coward in this thread which basically states: "we-don't-work-for-you-and-we-don't-care-if-you-use-our-software-and-you-should -just-learn-how-it-all-works", nicely illustrates the mentality of certain members of the Linux community. It doesn't take all that many of such responses to drive someone off who is posting uninformed (but to the poster important and perhaps puzzling) questions and perhaps complaints in the help section of a forum.
I believe that Linux being free has nothing whatsoever to do with its value perception.
Instead I believe that people, and to some extent correctly, still equate Linux with "something for geeks, not end-users" because of:
- the generally poor standard of GUI's on Linux itself and Linux software
- the generally dismissive attitude of Linux users / software developers for a nice polished GUI with all the details taken care of.
There ... I've said it. So flame me.
Ordinary users simply do _not_ want something that forces them to go to the command line for system maintenance. Neither do they want to have to edit configuration files, let alone scripts. It has taken Linux distributions years to come up with something as sophisticated as YAST (for SuSE Linux) and KDE Control center, and especially KDE still doesn't provide a reliable one-stop solution to detect and install my inkjet printer. I have to go to CUPS for that. In a word ... it's less simple than MS Windows (unless you already know what you should be doing because you did it before and kept notes).
I have seen threads with expostulations about how great command line oriented programs are, and I agree ... for some programs that are oriented towards batch processing, for repetitive jobs, and for software that I write myself for my own use. (When I write software for my own personal use, I never write GUIs. Command-line, control files, and file in, file out. If a GUI is needed, someone else can do that.)
But for other people's programs, and for programs I don't use every day I want to be prompted and guided ... by a GUI ... with tooltips and a smoothly functioning and fairly complete Help function. The very last think I want is to be obliged to read a manual and remember commands for some fink of a program before I use it. I believe I have a typical end-user mentality in this respect.
And did I mention that as an end-user I really do _not_ want to see every program sporting its own GUI layout either? I don't care a fig about what some programmer thinks is good way to organise his GUI. I want my GUI to be *standardised* (at least the toolbar) so that it's somewhat familiar as soon as the application starts. Copy-paste should of course be supported, and don't you dare to let it default to any other key combination than C for copy and V for paste, and a print option (if applicable at all) right where I expect it ... under the menu (which has to be the leftmost menu) somewhere 3/4 down the list.). Well ... I might be able to cope with a standard GUI layout under Linux that's different from Windows, but no more than one.
And then the graphics itself ... ouch. I really *hate* GTK-based programs. They look somewhat like the Windows programs I'm used to, but the widgets work differently. I find them clunky. Ugly and clunky. Again, I couldn't care less what some programming community thinks of them. I don't want them. Take the typical GTK file menu for one thing. An abortion! And what's more, I won't have them unless there is no alternative.
As an illustration, take for example AviDemux (see here: http://fixounet.free.fr/avidemux/). It comes in two flavours: with a GTK+ interface and with a QT4 interface. I tried the GTK+ flavour first and disliked it. The QT4 version on the other hand was acceptable. It didn't irritate.
The good news is that this nicely illustrates the difference between what in the context of "Git" (the version control software) is called: the plumbing (the guts) and the porcelain (the superficial layer that comprises the GUI). A well-designed GUI can be rendered in either GTK+ or QT4, and it should have absolutely no impact on the plumbing.
I submit that there is a fairly sharp criterion for detecting "real" AI: the Turing test. For a robotic equivalent of a human body this might be the tie-your-own-shoelaces test. Of course lots of subjects have emerged that could be studied in isolation and which yielded useful and definite knowledge, but were originally lumped under "AI" because people thought might help them on the way to create a "real" AI.
To me this mostly illustrates the fallacy of thinking: "If we could only solve this problem, we would have AI". So far it has turned out to improve our insight in what the Human mind isn't, and in parts (neural networks) how parts of it (probably) work. Both impressive achievements, but nothing in the way of constructing an AI that can e.g. pass the Turing test or tie its shoelaces. But those specialist subjects tend to lack the hype that surrounds "AI".
In this vein I think it's either an act of total irresponsibility to sell, what basically amounts to a wild-ass guess, as a "prediction" of the type the article mentions, or a deliberate attempt to use the "AI" hype with the sole purpose of obtaining funding.
That's enough. Err ... frankly your reply has given me pause. Seriously. It betrays a wealth of misunderstanding about AI and computing in general, and I have been wondering if I my reply should be a sarcastic one or just an explanatory one. Given the nature and the depth of the misunerstanding displayed here, I have settled on an explanatory one.
What you call "Automated scheduling" is part of a branch of applied mathematics known as "Operations Research". Basically it's the art and science of formulating a practical, real-world problem (such as air-crew scheduling, devising FedEx routes, loading aircraft, routing goods flows through transport networks as efficiently as possible, finding optimal stock portfolios, finding optimal ways of running an oil refinery, etc. etc.) into a mathematical problem, (usually a so-called "optimisation problem; see http://en.wikipedia.org/wiki/Category:Optimization_algorithms) and then devising appropriate solution algorithms that can be executed by a computer (usually a digital one) to give exact or approximate optimal solutions to said problem. See also: http://en.wikipedia.org/wiki/Operations_research
Such problems can be quite large ... e.g. with thousands of variables and tens of thousands of constraints. Now I'm confident that you would be quite unable to solve a 2x2 LP problem (i.e. a Linear Programming Problem, one of the most basic Operations research problems) in your head, or a 3x3 problem using pen and paper. Any PC can run a program that solves such problems in microseconds. This however has nothing to do with the question of whether solving an LP problem is to be classified as AI or not. As a matter of fact, solving LP problems is not, and has never been, considered part of AI. The same holds for all the other OR problems I mentioned.
Now it turns out that many of the problems I mentioned don't have what are known as "efficient" solution algorithms. Meaning we don't know of any exact solution algorithm that has polynomial run-time on a digital computer; instead all known algorithms have *exponential* run time on a digital computer. In such cases one resorts to what are known as "heuristics" (see http://en.wikipedia.org/wiki/Heuristics#Computer_science ), being algorithms that aren't guaranteed to find an optimal solution, but which sometimes *can* be guaranteed to come within say p% of the optimum, or at least to come up with a fairly decent solution. Some of the heuristics used, e.g. what are known as "branch-and-bound" algorithms (see http://en.wikipedia.org/wiki/Branch_and_bound) are based on questions that were (also) encountered or raised in the study of AI.
The important thing to note is that in general this has nothing whatsoever to do with Artificial Intelligence per se. Artificial Intelligence (AI) research on the other hand deals with problems like: "How can we induce computers to exhibit behaviour mimicking the Human Mind, or the Human body" (see: http://en.wikipedia.org/wiki/Artificial_intelligence))
Note the lack of overlap between Operations Research (OR) and Artificial Intelligence (AI) problems. The m
So far _not one_ of those claims has come true, with the possible exception of the the much-vaunted "robotic snake".
So ... I'd say: less claims, fewer predictions, and more work. Let me know when you've got anything worthwhile to show.
Not to be outdone by forecasters, I have a forecast of my own to make: before the term is us it will transpire out that all this fanfare and this announcement were only ever meant as means to attract research grants.
However ... I do see a few probl... err ... I mean of course "Opportunities" here.
The first one being the opportunity to convince management in the US to pay engineers and scientists more and/or MBA's less.
The second one would be to convince them to stop seeing the engineering and R&D departments as regrettable cost centers to be outsourced and/or off-shored at the first opportunity.
The third opportunity would be to convince industry to offer Ph.D's opportunities (and to some extent academic entry-level positions) that make it less of a financial risk to do a Ph.D.
Prospects for Ph.D's (depending on discipline of course) can be so awful that you have to basically tell students: "Don't do a Ph.D. unless you (a) really derive fulfillment from doing research / teaching even if you're paid half to 1/3 of what you'd get in industry and (b) you are in the top 5% of your class, or you won't be able to get tenured".
Well ... industrial espionage is part of doing business. Between companies as much as between countries. Besides, trade is a two-way street. It's not as if the US are providing China with development aid. The US are benefiting from cheap Chinese products too. Have you ever considered what the impact on the US would be if there were to be say, 30% import tariffs on Chinese goods?
All those PC's, printers, T-shirts, hand tools, shoes, toys, and what not? First you'd kick off a vicious round of inflation if you did ... plus you'd be seriously hurting the bottom line of such all-American companies that have off-shored their manufactoring operations to China (just think of HP).
Generally speaking, you'd saddle lots of US companies with higher costs which would make them vulnerable in the current economic downturn *and* make them less competitive with e.g. EU-based companies.
Sure ... it would hurt China. They might even have riots. But it would hurt the US too. Very much so I'd say. So let's just be very sure about the cost-benefit ratio of such measures before we seriously propose them, ok? Like it or not, the US is as much networked into the global economy as China, the EU, and OPEC.
It's not to say that the US can't rescind China's "most favoured nation" state. Of course it can! The question is: what are the costs and what are the benefits. And I submit that the costs just might be a bit steep for the satisfaction of making our displeasure about industrial espionage known.
Nothing new there. Besides, I'd be amazed if e.g. India, Pakistan, Brazil, South Korea, Japan, South Africa, and Iran weren't also active (or trying to be active) in this field.
Why then do we hear often about Chinese espionage? Is it just that Chinese espionage makes good headlines?
Well ... perhaps it has something to do with the fact that there are so many (very good) ethnically Chinese engineers and scientists in the US, in all walks of life. Due to do Americans not being interested in an arduous career in Engineering or the Sciences when they can instead aim at Management, Legal services, or brokerage I'm told. Well, admittedly the Chinese government is quite organised about industrial espionage, and it's easier to get a rapport with an ethnic countryman than with some foreigner.
So ... if we assume a fixed promillage of the population open to espionage proposals, we must expect Chinese to be over-represented.
Besides which ... it's not as if the US doesn't commit industrial espionage of itself (primarily in the EU; see e.g. http://www.guardian.co.uk/world/2000/mar/31/ianblack).
Lets just save our righteous indignation for a more worthy cause and simply shore up security on projects and firms that are attractive targets, shall we?
However, much as I like Open Source Software in general, I consider it perfectly OK if people decide to use commercial, closed-source, anti-virus software. I would urge them to (re)consider using such software in favour of OSS, but if they wish, for whatever reason, to spend their money on closed-source anti-virus software, then best of luck to them (and the producers of closed-source AV software).
What galls me in this case is the unfair way in which Trend Micro uses a blindingly obvious patent they somehow got their hands on to squeeze an OSS competitor out of the market. The patent, basically the idea of having a virus scanner on gateway servers to a network that scans incoming files as they are being transmitted, is of course trivial.
Why?
The idea that in order to prevent infected files from entering a network, you can do the checks "at the border", i.e. in the gateway server, is about as obvious as the idea of keeping a place dry by having a roof and 4 walls. Since the incoming files aren't stored on the gateway server but immediately forwarded, the only thing you can do is to stream the incoming file through an AV scanner. Patenting an "invention" like that is of course only possible in the US.
Unfortunately the law says that even such patents have force, so an unscrupulous commercial AV vendor (Trend Micro) can use it to sue people for doing this.
That's why I'd support a boycott of Trend Micro. Not because they're closed-source vendors, but because they behave like thugs.
No, it is not. It is simply faced with a single-minded regulator which takes its job seriously and isn't fazed by the fact that Microsoft is a brazen repeat-offender.
GM does not have an 80% market share in the car market. Microsoft does have such a market share in the desktop OS market. That's a big difference.What Microsoft is currently doing with OOXML is a thoroughly unethical (paying companies PR contributions to vote in favour of OOXML, offering small countries rebates to vote in favour of OOCML, and suddenly stuffing ISO standards committees with pro-microsoft members who never before had an interest in ISO procedures in their lives) attempt to continue its lock-in, which regrettably seems to have a chance or working. (see e.g. http://www.consortiuminfo.org/standardsblog/article.php?story=20080208082501776 and http://www.theregister.co.uk/2008/02/08/ooxml_eu_probe_iso/ )
I see absolutely nothing to salute Microsoft about regarding its determination to disregard fair-competition and anti-trust regulations and I support the EU in this matter. Why don't we see any US regulators step up to the plate?
Assuming for a moment that the link you provide does indeed contain the law that governs this particular case, further reading should have shown you this:
(3) Termination of the grant may be effected at any time during a period of five years beginning at the end of thirty-five years from the date of execution of the grant; or, if the grant covers the right of publication of the work, the period begins at the end of thirty-five years from the date of publication of the work under the grant or at the end of forty years from the date of execution of the grant, whichever term ends earlier.
As I read it: if you grant someone a license on copyright that you own then you have to wait 35 years before you get a 5-year period during which you may revoke your earlier grant.
Now I'm not completely sure if that's how the law should be interpreted, but it clearly shows the ill-advisedness of trying to interpret the law as amateurs. Instead I suggest you seek an informed opinion such as e.g. Groklaw (http://www.groklaw.net/article.php?story=2006062204552163)
With the word "threatening" I referred to the essence of your post, which is to deny that Trend Micro accused ClamAV of patent infringement. It did. Denial of the main issue on a mere point of phrasing is not the way an honest debate is conducted, let alone with the language you seem believe is appropriate for you to use.
Apparently I have to be a little more precise to deny you any wiggle room that might allow you to use a loose phrase on my part as a cop-out. Well, here goes.
See this link:
http://www.usitc.gov/ext_relations/news_release/2007/er1221ee4.htm
The investigation is based on a complaint filed by Trend Micro Incorporated of Cupertino, CA, on November 21, 2007. The complaint alleges violations of section 337 of the Tariff Act of 1930 in the importation into the United States of certain systems for detecting and removing viruses and worms, components thereof, and products containing same that infringe a patent owned by Trend Micro. The complainant requests that the ITC issue an exclusion order and cease and desist orders.
See the highlighted bits? Just to make things explicit for you: they show that Trend Micro really *did* accuse Barracuda of patent infringement. It did this by filing a complaint with the United States International Trace Commissions (USITC). Notwithstanding the fact that the USITC is not a district court, this clearly shows that Groklaw's report is correct, and your off-hand opinion is wrong.
Having settled that, the ZDnet article notes that Trend Micro had sent Barracuda a lengthy series of legal correspondence pointing out that in their view Barracude either had to pay them or stop using the OSS program ClamAV. Now the only ground they could have claimed that on is by pointing out that Barracuda used CLamAV which, allegedly, infringes on Trend Micro's patent. Since the end user is responsible for patent infringement of OSS software they user, this in effect means that Trend Micro accused Barracuda of patent infringement. So the ZNnet article I cited shows the same thing, namely your claim that Trend Micro did not accuse Barracude of patent infringement is wrong and Groklaw's representation is right albeit not as authoritativelty as the press release from the USITC.
http://news.zdnet.co.uk/security/0,1000000189,39292511,00.htm
Since 2006, Barracuda Networks has been receiving communications from Trend Micro's legal team requesting Barracuda either pay licence fees when using ClamAV, or stop incorporating the software into its products, according to Barracuda's chief executive and president, Dean Drako.
I don't know what you consider threats then, but if company X tells you to cough up or stop using an OS package that they claim infringes on their patents, *I* would consider that a threat.
I really don't see in what sense Groklaw supposedly made a mistake. In fact I think Groklaw's presentation of fact is correct. Unless you can point to solid evidence that shows otherwise I'll just have to assume that you misread the material you saw.
I really don't see the problem, do you? I'm certain it will all be legal, so there's nothing to worry about. No. Really.
This bias however has nothing whatsoever to do with:
- the quality of their editorial opinions (as opposed to Slashdot they actuall *have* an editorial opinion, counter to Slashdot they are actually knowledgeable about legal issues, counter to 99% of Slashdot they actually read the stuff they write about. Besides, I haven't seen them shown wrong yet, mostly the opposite.)
- the quality of their reporting is quite impeccable (they show you where they get their data from, they tell you what they base their opinions on)
Lest you make a serious logical mistake, differentiate between your scepticism regarding their sources and their actual knowledge(which have so far proved impeccable) and their opinions (which you may be sceptical about but which they clearly highlight).
Better a knowledgeable site that has a bias (which it is honest and up-front about) than a whole stampeding herd of ignoramuses with a 10-minute attention span.
The article did mention some concerns from DOH officials about the potential for false alarms. Requiring regulation for geiger counters or air quality monitoring equipment is a bone-headed, inappropriate, and totally disproportionate response to potential problems.
It seems as if the DOH has too much time on its hands. That's what you get when you create a whacking big government organisation: the whackiest ideas sudenly get support within it and are then solemnly passed off to external organisations as: "This is what we advise you to do because there *might* conceivably be drawbacks if you don't"
The first one to check is of course Groklaw, which provides the following answer (see http://www.groklaw.net/article.php?story=2006062204552163): "No. One can't retroactively revoke licenses previously granted, unless the license terms allow you to do so. The most you can do is stop granting new licenses."
Simple and just as you would expect.
Well ... first off we'll make allowances, this being Slashdot, but *sometimes* it helps to read the opening post. Don't let me talk you into anything unnatural for you, but I'd just like to put it forward. As a suggestion you know? For you to err ... think about.
In this case the opening post gives some interesting clues as to the problem the poster is facing. Read with me if you will:
This explicitly tells the interested reader two things:
- the poster is confronted with a large unfamiliar code base
- he isn't even familiar with the target platform
- his job requires is that he has to get this codebase under control pdq
- he's brand new new to his job
Those who, reading between the lines, infer that he hasn't got any proper documentation for said codebase can get bonus points.
The poster further writes:
This tells the attentive reader one more thing. Just reading the code wasn't helpful. That's what the man said. So ... printing the stuff out and playing "Little Picasso" with coloured marker pens won't be much of a help either, ok? This isn't about regaling people with unverifiable anecdotes of your personal programming highlights, it's about providing the author with sound and practical suggestions that he can use in his job.
Even close reading of my previous post fails to reveal any claims on my part to the effect that e.g. version control or instrumenting memory allocations are crucial to understanding the code base. They are simply sensible precautions any software engineer would take before
(a) karking around with a huge code-base he can't make head or tail of, and
(b) assuming that whatever code he's been handed doesn't contain a lot of goofy mistakes that will come to bite him as soon as he changes anything.
This guy is going to be *responsible* for that code-base. For his *job*. His *brand new* job. And he's asking on *Slashdot* for tips on how to tackle a new code-base. Well ... pardon me for leaping to the conclusion that he needs some help here and that he isn't too experienced in dealing with real-world software maintenance. So let's just forget to mention that he should establish a baseline of the code-base he has before touching it, shall we? Might be good for a couple of laughs when he finds out and can't revert his changes. Tee-hee-hee.
Oh yes, and when would you like him to find out about any memory allocation problems? Right now, or when he's under a deadline to make modifications to the code-base that may play merry hell with whatever allocations that have been hacked into working? And as said ... reading code isn't going to clue you up much regarding any memory allocation problems. It it were, then we wouldn't *need* code instrumenters to check for memory allocation problems, ok?
As to tracing and profiling. Think you can infer the execution path for the normal case of a non-trivial program you know nothing about by reading it??? Is that what you're saying? How do you know that the top 20% of the code doesn't deal with test-cases and verification of whatever input that that program takes, and was left in because it was considered handy to have that right next to the production code?
Well ... some good points, and some I'd say are too detailed at this point.
I totally agree with point (1). I forgot to mention it since I assumed (always a bad thing) that the author actually could compile and run the thing. An important point to keep in mind. Thanks for bringing it up.
Points (2)-(5) however all come after you've understood the basic structure of your code base.
Next, I'd say that a fairly junior software engineer trying to tackle a large unknown code-base without proper tools is doomed to failure no matter what. So the step from "If you're in a rush" and "You are in a paid job and expected to deliver predictable results." to "forget about tools you're not familiar with and just dive in" is an exercise in self-delusion and a recipe for disaster. Nothing less. It's like someone rushing out of the house and sprinting for work because they don't know where they put the car keys or their bus ticket and feel they are too much in a rush to search for them.
Besides, producing automated documentation is a good way to communicate. The tool communicates the structure of the code-base to you, and you can use e,g, the call-graphs to (efficiently) communicate the complexity (or otherwise) of the code-base to your supervisor. It also communicates to him how you are approaching the problem, which is likely to be a plus.
Now suppose the codebase is really difficult. A competent software engineer is, like any other kind of engineer, co-responsible for making actual and potential trouble spots *visible* to management. Preferably before they explode. Although it's popular wisdom to despise Management, if you, the hands-on person, don't tell Management of the problems, you ensure that they're driving blind. You rob them of the chance do do anything about it before the problem becomes so acute that even they'll have to notice. They will recognise it if you do and keep it in mind when they have to assess you. Depend on it. Besides, you just happen to be the only one who can tell them, and you fail in your responsability if you don't. Part of a software engineer's job is to *communicate*. Now you can't give your supervisor any honest estimate of how well you have the new code base under control before you get to know it. And tools really really help you save time and allow you get a much better overview.
Communication works both ways. If, with all the tools you use, you are unable to understand the code-base, you lack one or perhaps two elements that distinguishes a basic software engineer from a good or even a great one. Talent and experience. And you should be honest with yourself and your supervisor about that too. If the job really is too hard for you, have the guts to own up before you mess up and thereby save yourself and your company a lot of trouble. And believe me ... there are lots and lots of good jobs in software development / maintenance that can be done without a surfeit of either. Such is the power of engineering.
Now Doxygen (or similar tools) may be unfamiliar to the author, but such tools really work. Besides, I've seen students download, understand, and use Doxygen in less than 1 hour after they were told about it.
In fact, it nicely highlights the difference between "software engineers" and "code monkeys". Code monkeys just dive in; they never pause to think. In fact ... they tend to avoid thinking. It's not their strong point. After all ... they're paid to code, right? Not to think. Software engineers on the other hand, look before they leap and spot the places where they need to pay attention first. And they're systematic about it.
In fact, a software engineer will happily spend a day or two putting the right tools in place, *including* a full backup and a proper version management system for when he's going to have to touch anything.
The first thing you want to know about a new code base (after you find out what it's supposed to be doing) is its structure. Tools like Doxygen (see previous posts) show you that structure *far* quicker and *far* more reliably than any amount of dumb code-browsing can. And besides ... once you do it, you've got that documentation stashed away securely instead of milling around incoherently in your head (you'll have completely forgotten most of what you read by next month) or on disorganised pieces of note paper.
The second thing is to figure out if it calls any "large" functionalities like subroutine libraries or even stand-alone programs like databases, let alone if it makes operating system calls. The call-tree will give you an excellent view, and the linker files can complete the picture. You wouldn't be the first maintenance programmer who found out after months that his application critically depends on some other application he wasn't told about.
The third thing is to see where your code does dirty things. Let the compiler help you. Just compile your application with warnings on and have a look at what the compiler comes up with. You might be surprised (and horrified). Then compile with the settings used by your predecessor and check that your executable is bit-for-bit identical to what's running (you wouldn't be the first sucker who's given a slightly-off code base).
If performance is at all important, then running the whole thing for a night on a standard case under a good profiler will also tells you lots of important things. Starting with where your code spends its time, where it allocated memory and how much, and where the heavily-used bits of code are. All neatly written down in the profiler logs.
Finally, run your application with a tool to detect memory management errors the first chance you get. Useful tools are Valgrind (in a Linux environment), Purify (expensive, but probably worth it) under Windows, and sundry proprietary utilities under Unix. Just about 90% of the errors made in C programs come from memory management problems, and half of them don't show up except through memory leakage and overwritten variables (or stacks .. or buffers .. or whatever). You'll need all the help you can get here, and as far as these errors are concerned, dumb code browsing is useless. Just keep your head when looking at reports from such tools ... they can throw up false positives. Ask around on a forum with specific questions if you're allowed, or ask your supervisor. After all ... you showed due dilligence.
When you know all that (if you have the tools in place, all of this can be done within 1 day + 1 overnight run + 1 hour reading the profiler output), go ahead and trace through the code in a debugger. You'll be in a *far* better position to judge what you should be reading.