Slashdot Mirror

1. Clippy: Misunderstood animated pedagogical agent or spawn of Satan? - Invokes Sun Tzu

2. Why People Hate the Paperclip: Labels, Appearance, Behavior, and Social Responses to User Interface Agents. Impressive 65 Page PDF available from this abstract page.

3. People Who Hate Clippy, the Stupid Paper Clip from Microsoft Word (Wartburg Chapter). Emergency outreach

4. Meme:Clippy. Fanpic uploads @ end.

5. On Youtube.

6. How I Made Clippy Lovable. Stanford again. What is it with these guys? You know their mascot is a tree?

7. DEVELOPERS DEVELOPERS DEVELOPERS. I think my nose just started bleeding.

8. Et tu DARPA?.

9. Senor Pedaso Molesto de Matal NPR transcript.

10. Back At'chya. Remember before they became inertia?

11. Hark the Herald.. Wait, DIE DIE DIE. Just sayin'.

12. Reflection.

Happy Clippymas! Hope the leaks result in a zillion times the cogitation invested in Clippy..

That said, there's a system now that could change all of that. It's called MSBuild and it ships with Visual Studio. For anyone who does command line builds and whose codebase is mostly managed code, I highly recommend looking into it.

Eh, you do know that such tools have existed for quite a while now? You might want to first check out Apache Ant, or if you're a .NET developer then take a look at NAnt instead. You'll find a good introduction to NAnt here.

Once you've gotten the hang of (N)Ant you might want to set up a automated build server: CruiseControl or CruiseControl.NET

I'm normally a big fan of MS development tools, but when it comes to automating the build process MS is really playing catch up.

Nearly all examples use in-line SQL queries rather than paramaterized stored procedures.

Ooh, like the personalized internet assistant, Bonzi Buddy? Or maybe it will be as widely loved as Clippy.

Poetic justice, maybe they should talk to Borland how this feels.

Software is not patentable. So why are they persisting to do wrong?

Here's a thought as to why they don't yet get it (nobody wants to tell them why its really not patentable.)

In regards to dealing with increased complexity in software MS has their longhorn and their software factories effort, free software has its edos project, neither of which are in promotion of honesty regarding programming, or what is the application of abstraction physics.

Its really quite simple. To support the non-patentability of software the foundation upon which software is created must be supported the same. Free Software development community doesn't want to do this anymore than proprietary software campanies.

For its always about money based upon some mode of elitism. With Free Software its the service oriented products/applications and complexity out of teh reach of most customers, with proprietary software its exclusive use.

But if the arguement that software is not patentable due to its abstract ideas status, that anyone is capable of abstract logical thought and ideas, then that status has to be supported by making software obviously easy enough that the "free software" label will be because software is easy enough to create that its free in the sense that anyone can create it or cause the machine to, regardless of their knowledge resource. (you don't need to know how a calculator works to use it to calculate an equasion you input or hit the key that does some equasion for you - ie pi)

How do I know this? In a email to various participants of Edos, (Of which experience tells me not to expect any support for honesty about abstraction physics. Or any indication they got the email, as avoidance seems to be thought to be proof against something the thing being avoided), I wrote:

RE: press release "Major European research institutions and Open Source software companies today announced the launch of EDOS, a project dealing with complexity management in the field of Open Source software. The participants will collaborate in the development of theoretical and technical solutions to the management of large-scale, modular software projects..."

Abstraction Physics is the foundation of the practical application solutions. Deal with that, establish the mechanics and create the software mechanism and the rest will come easy (or boringly repetitive), where there is plenty to apply "navigational mapping" to and productively exaust the funds on and I believe to accomplish a lot more then thought possible regarding the EDOS goals.

from: - ffii.org - Software Patents
to: Advances in software are advances in abstraction
Then to: Abstraction Physics

Microsofts direction with longhorn.

Google search "web" for: "Timothy Rue" patents a few links from that search are here
and here (-see comment #4 - I'm/VIC USPTO published protected!)

I can wonder why the USPTO edited my comment and removed the near transparent markup but here is the version I sent them (with contact information limited). Also this google finding.

The Virtual Interaction Configurationion project is GPL'd (forkable and all the other things allowed) and would amount to maybe a drop in the bucket, in comparison to the funding and manpower the EDOS project has available, it could be completed and I believe used to surpass the goals of EDOS.

Current state is that of needing some correction and completion in the current python code, integration of the existing IQ and ID commands and the c

When I read stuff like the above I'm inclined to think a project went sour, and blame was put to rigidly following UML with no clue why, how it works or what for. Hey we did it the right way and still failed, what gives?

Well, here's the next silver bullet, I mean paradigm. For some of the controversy, read Grady Booch'sDec 3rd article. Actually, DSLs look interesting, MSFTs proprietary "Software Factories" do not. They lament the fact UML is too limited. It seems that if you dislike UML, you'll really dislike their "vision".

Seems that was the way that Miguel used to see Avalon, and the almost-defunct WinFS (check out ReiserFS4 metadata, btw), but now, surprise, is not!

Check this out:

"They are all fine points of view, but what makes Longhorn dangerous for the viability of Linux on the desktop is that the combination of Microsoft deployment power, XAML, Avalon and .NET is killer. It is what Java wanted to do with the Web, but with the channel to deploy it and the lessons learned from Java mistakes."
http://primates.ximian.com/~miguel/archive/2004/Ap r-24.html

"Avalon will be a lot easier to write than the previous ActiveX; it's a lot prettier, so when organizations are using Longhorn-based machines, which I assume will be sold everywhere by 2008, it's going to be increasingly hard for the rest of us to get there unless we have an implementation of an equivalent technology."
http://www.theserverside.net/common/printthread.ts s?thread_id=27453

"Longhorn has kind of a scary technology called Avalon, which when compounded with another technology called XAML, it's fairly dangerous. And the reason is that they've made it so it's basically an HTML replacement. The advantage is it's probably as easy as writing HTML, so that means that anybody can produce this content with a text editor."
http://news.netcraft.com/archives/2004/04/28/inter view_with_miguel_de_icaza_cofounder_of_gnome_ximia n_and_mono.html

So, what was all that crap that he told us "fear Microsoft, you morons, we need something like they have to have more 'competition' there" about?

A big FUD? A way to try to implement and waste time with, all we know, some probabily vapourware or with a product that does not work well? Think about WinFS. He also used to say that it will be the doom for all the Linux users don't have a stuff like that, but even the Microsoft users will not have a stuff like that, at least the way all the utopic dudes wants to!

Now that the technology owner is in trouble with it, he says that it's a lot of shit? Oh, come on.

The big point here is that, with some effort, you don't need Microsoft programs anymore to do what your company needs to run your computers. And we don't need people trying to convince us that WE NEED THEM if we really don't need. Gimme a break.