Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Semantic Computing

By jonnyfantastik in Technology
Fri Apr 27, 2001 at 10:55:25 PM EST
Tags: Software (all tags)
Software

In Star Trek a program written on Klingon hardware in the Klingon language can destroy hardware developed across the universe. I can't even solve the RPM and DEB problem.

Why can't we abstract the entire process of computing?


Anybody's who's ever watched Star Trek has witnessed the amazing feats of portability and interoperability that regularly take place in the future. A virus written by humans on human computing systems will not only automagically run on alien hardware it will also work -- and trash the hostile alien's base defense systems. File formats and data storage from a million year old civilization are easily read and manipulated. Aliens will sneak aboard the Enterprise and, having never seen the Federation user interface or used its computing systems, will begin hacking away and turn off the warp core as well as override all manner of authentication devices.

Is this just Television stupidity?

To an extent, yes. And yet, it's not impossible to believe that this level of interoperability and portability is available today. We have the tools in the form of XML and the Internet and URIs. Yet we still live in an interoperability hell - a mishmash of operating system, hardware, and software environments and, I speculate, we waste millions of dollars, yes waste, making these work in 'heterogeneous environments'. this is just plain dumb. Things don't have to be like this.

Any good programmer in the world can tell you the power of abstraction. Abstraction is a design methodology, a way of thinking, in which the complexity of a system is reduced by concentrating only on the interfaces between components and not the implementation of components. Every component is like a black box with a series of well defined inputs and outputs. What happens inside the box - doesn't matter. When complex systems are abstracted in this way you can do amazing things. Programming represents this in its onward march from machine code to assembly to low level programming language to high level languages to object oriented languages to finally generic programming and component programming. Abstraction is power.

Abstraction seems to be applied everywhere but operating systems itself. Few people have realized it because they're so caught up in the idea of the Semantic Web , but the same idea can be applied to computing systems itself. I claim that many of the most common tasks in computing can be abstracted into abstract processes and standardized across the universe. This is how we make Star Trek portability and interoperability real. Consider the following examples.

Software Installtion:

This is one of the most potent examples I can imagine. Why is it that installing software is so hard and so different from system to system? This makes absolutely no sense. The fundamental abstract process of installing software is _always_ the same. You locate the software, download it, and then install it. You recursively apply this formula to the software's dependencies. Voila! Software installed. Note that this is an abstract process. Nowhere do I mention anything about operating systems or software package formats. In fact, I never even mention anything about a software package - I talk only of the abstract concept of 'Software' a program I want to run on my computer. Software installation is something which could definitely be standardized and applied across _all_ operating systems.

How do you do this? Using XML, of course. Imagine this: user A loads up website B. Navigates to the website of a software program he wants and clicks on a button 'Easy Install' (he won't have to pay because this is free software!). His browswer downloads the XML file and plugs it into a generic software installer program. This installer program, which knows about all the things that vary from user to user like distribution, kernel version, hardware architecture, and shell, processes the XML file and decides whether to install an .rpm or a .deb or even a stuffit archive (for Macintosh users) or a .zip for Windows users. The benefits of such a system are tremendous. It exhibits all the good characteristics of good computing. It is scalable -- you could easily use it to download whole operating systems. Or better, let's say you have to install program X on 100 workstations , easy peasy, just send the install file to each one where an update daemon is waiting. For some reason you have to reinstall your OS and reinstall all your software? Again, problem solved. Just move all the old XML-install files from your old computer to your new computer. This system is very flexible. It doesn't matter what software you're downloading as long as the maintainer has provided an XML-install file which contains the right data, you can download the program with a click of a button. Such a system would be especially potent on Linux where users are tortured with a variety of packagement strategies from rpm to deb to Slack. The obvious solution is to remove package formats entirely from software installation -- you abstract it out of the interface and into the implementation. In order to make this system work your operating system must support three trivial functions through a common POSIX-style API. One function is passed a unique string identifier* (which identifies a program) and a version number and returns -1 if a previous version is installed, 0 if it's not installed, and 1 if it is. Two other functions are a common api into some sort of database (it could be another XML file or even a MySQL database) for adding and deleting the names and version numbers of programs which are installed and uninstalled onto the computer. Imagine, the same 10kb XML-install file you download to install vi on your RedHat box also works on your Debian, FreeBSD, and Windows2000 box. Now that's interoperability.

System Initialization:

This is another area where semantic computing can pay off big time. Anybody's who's ever had to manage RedHat boxen and Debian boxen know what a gigantic hassle it can be to mess around with SysV and BSD style initilization. But this is the stupidest thing I've ever seen. What a box does when it boots up rarely has anything to do with its operating system -- usually it's just a matter of 'execute script X', 'run application Y'. So why can't we abstract initialization? Why not have one XML file with tags like <start_app> and <run_script>. Then different operating systems can process this XML file to the best of their ability. Again -- abstraction is the key -- concentrate on interfaces and ignore implementation. Imagine how nice it would be to simply put one file on tons of different computers and never again worry about initialization?

Resource Location, Service Discovery:

User X downloads file in format Y. Error! You need program Z to use this format. User A tries to install program B. Error! You need the python interperter ... but wait, User A has just spent the last hour installing JPython which can execute python scripts. What's going on here? The simple answer: idiocy. The complex answer is that vendors aren't working together to bring to individuals what businesses are already discovering in the form of Internet Yellow Pages and the like. Very often when you are dealing with a completely unknown computer over the internet you have one question: 'Can you do X?' Note that there is a gigantic difference between asking whether the python interperter is installed and asking whether a computer can execute python scripts. In Market-tease this is known as 'Service Discovery'. In truth, this is just common sense. And again, using XML and a common API which all operating systems could easily implement, it would not be difficult to answer the question 'Can this computer execute python scripts?' or 'Can this computer play quicktime movies'? All of the stupid little details that vary from user to user and program to program like file formats and operating system should be abstracted away. This is also relevant in the resource location dilemma. Many times a program needs to know the location of certain data like pixmaps and i8ln data. On Unix to accomplish you use environment variables (which are ugly and a hack) and symlinks with everything in a common directory, on Windows you put everything in the same folder as the executable ... all of thportability, you'd think programmers would've realized the power of a common api and XML here. The fact is, a program doesn't care where its resource data _goes_, it just wants to know where it _is_. There is a subtle but powerful difference. This is why programmers are often told to never code absolute file paths into their code. Because this is a a very variable and OS-dependent thing -- it's something that varies. is is dumb. In the mere interest of portability, you'd think programmers would've realized the power of a common api and XML here. The fact is, a program doesn't care where its resource data _goes_, it just wants to know where it _is_. There is a subtle but powerful difference. This is why programmers are often told to never code absolute file paths into their code. Because this is a a very variable and OS-dependent thing -- it's something that varies.

And that's what abstraction is all about. The point is you localize the things that vary . Whatever it is that changes from user to user be it distribution or hardware you ignore it, leave it out of your design. The classic case of this is a computer itself. The hardware of a computer is completely abstracted: each part, from memory to video card, is a well defined black box with only a clear interface. The monitor never makes any assumptions about how the video card works and vice versa, they operate strictly through a well defined interface. This is powerful, this is flexible, and this is simple common sense. Why can't the power of abstraction be applied to computing itself? Computing is a process. Word processing, entering data into a spread sheet, installing software... all of thjese are processes. They should be abstracted and standardized. Once the entire process of computing has been sufficiently abstracted, all kinds of things be~come possible. Imagine switching your entire operating system... on the fly! Star Trek portability and interoperability is really not as outrageous as you might think.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Also by jonnyfantastik


Display: Sort:
Semantic Computing | 47 comments (41 topical, 6 editorial, 0 hidden)
A comment (4.62 / 8) (#3)
by RangerBob on Fri Apr 27, 2001 at 08:47:30 AM EST

I'd highly recommend that more people start learning more about the history of computer science/computers/etc. I've noticed that a lot of "new and nifty" ideas on here are actually old ideas (not slamming anyone either so don't go getting defensive). In fact, there's a large number of computer science "advances" today that are old ideas. For example, the idea of multithreading has been around since the 50's. What's interesting is that you'll find that a lot of things follow a sine wave, where there're really popular, then fall out of favor, then get rediscovered and become popular again.

Why am I pointing this out? Because there have been a few things posted lately that have been well discussed and thought out already. Some of them have been found to be bad ideas, others are quite good but can't be done yet.

not to nitpick but... (none / 0) (#28)
by Kalani on Sat Apr 28, 2001 at 06:06:04 PM EST

What's interesting is that you'll find that a lot of things follow a sine wave, where there're really popular, then fall out of favor, then get rediscovered and become popular again.

That'd be a cosine wave, or at least a phase-shifted sine wave. ;)

-K

-----
"I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
--Richard Feynman
[ Parent ]
not to nitpick but... (none / 0) (#34)
by rbt on Sun Apr 29, 2001 at 10:07:27 PM EST

heh.. Probably actually a tangent from what I've seen. Really popular then overnight it becomes a tabo..

[ Parent ]
Good article. We're on that path. (3.87 / 8) (#7)
by jabber on Fri Apr 27, 2001 at 11:52:15 AM EST

You know, early on in the history of computing, people would argue over the number of bits that should comprise a byte. Then they argued about the number of bytes in a word. Then about the order of bits (this is STILL and issue), from most significant to least significant or vice versa. Then they argued about RISC vs CISC, and recently threw VLIW into the practicality mix. They argue about file formats and standard languages..

Point being, this is an evolutionary path we're on. We need to do what works now, and adapt the different things that work to one another as need be. Architecting a comprehensive solution to universal computing is probably just as difficult as building a human from the amino acids..

By that metaphor, we're somewhere in the protozoa stage of computing evolution. Ok, maybe a little further along.. Maybe we're working with slugs.. Maybe chick embryos, right iGrrl?

You bring up an excellent topic, and you present it in a very good way. It is very important for people to keep in mind that this is a huge issue. After all, if Earth ever gets invaded by aliens, Jeff Goldblum will need to be able to write a virus to cripple their invincible mother ship, and all that. Seriously, interoperability is a very important thing, and there are very many brilliant people working on it.

Returning to the evolutionary metaphor for the moment... Computing is nearing a hard limit of performance and storage. Universal interoperability will not be achieved before this limit falls to quantum or biological computing, but it will be achieved. Computation on the quanum level, or biochemical level, will assure a common architecture upon which to build compatible systems. After all, the lower you go, the fewer differences you have to make use of.

The process of evolution always seems to lurch ahead drastically after a major extinction. Once the current crop of IC and VLSI computers dies out in favor of new technologies, we'll see things explode.

[TINK5C] |"Is K5 my kapusta intellectual teddy bear?"| "Yes"

y only a '2' (3.00 / 3) (#9)
by syrrath on Fri Apr 27, 2001 at 02:09:06 PM EST

Point being, this is an evolutionary path we're on. We need to do what works now, and adapt the different things that work to one another as need be. Architecting a comprehensive solution to universal computing is probably just as difficult as building a human from the amino acids..
The analogy works to a point, except the problem is really a matter of no foundation to build their code/design on. Presently, everyone is building on their own limited and sparse implementations. It goes like this; the logic is the same but everyone is speaking in different tongues.

By that metaphor, we're somewhere in the protozoa stage of computing evolution. Ok, maybe a little further along.. Maybe we're working with slugs.. Maybe chick embryos,...
The stage is nearing its finality.. Unless you can come up with a problem within computational theory that is still problematic, i.e. something that can be described in formal terms and is not able to be implemented?
Returning to the evolutionary metaphor for the moment... Computing is nearing a hard limit of performance and storage. Universal interoperability will not be achieved before this limit falls to quantum or biological computing, but it will be achieved. Computation on the quanum level, or biochemical level, will assure a common architecture upon which to build compatible systems. After all, the lower you go, the fewer differences you have to make use of.
It could have been done in the late 80s but standard methods of despersed development limited it and nobody had any financial reason to do it. Anyone capable of coming up with the design for the "universal computing platform" would hardly be able to justify removing the ability to make money by coding... the eventual development would bring.
The process of evolution always seems to lurch ahead drastically after a major extinction. Once the current crop of IC and VLSI computers dies out in favor of new technologies, we'll see things explode.
You have that mostly right, the extinction just happens to be our culture and global pretense of control over knowledge... Of course, nobody can say when anything like that will happen, so you can ignore me for now.

--Singularity means to be infinitely connected. Who's up for working on one?
[ Parent ]

Theory vs Practice (3.66 / 3) (#10)
by jabber on Fri Apr 27, 2001 at 03:45:16 PM EST

I think your beef is really with the fact that a specific implementation of anything needs to protect itself against future improvements by competition. The idealism of 'let's all just get along' fails miserably when a company invests millions into developing an architecture. Why does the PIV still run x86 instructions??

Yeah, the problem could have been solved in the 80's. It could have been solved in the 60's or 50's as well, if nobody questioned Von Neumann and he didn't have to deal with people who wanted results 'yesterday'.

and nobody had any financial reason to do it

BINGO!

Why would anyone want to do anything right the first time?? You can only sell that once! Even if a car could be made to never wear out, do you think that any company would sell it? Money is made on upgrades.

The only way computing will evolve into a more easily unified system is when the performance and storage needs of the customer dicatate that implementation move to a lower, faster, bigger and cheaper level. Interoperability will come as a side-effect of making a profit. It makes no sense to make suicide by self-deprecation a goal.

So the evolution metaphor holds better still. Improvement and optimization only take place to fend of death.. No pain, no gain; this time meaning that a comfortable existence does not stimulate progress. Why do you think that the greatest leaps are made while nations fight for their very survival?

I think a '2' is only warranted if my above post isn't reflected upon. But hey! Whatever!

[TINK5C] |"Is K5 my kapusta intellectual teddy bear?"| "Yes"
[ Parent ]

Practice vs. Theory (3.00 / 2) (#19)
by syrrath on Sat Apr 28, 2001 at 04:07:26 AM EST

Money is made on upgrades.
The truth! The crazy part is the long term costs that so few ever look at (I know, in theory).

.. It could have been solved in the 60's or 50's as well...
The sheer number of possible and actual implementations of different types of architectures were and, to some extent, still are being developed prohibited it (even the lack of knowledge restricted it, back then). I'd argue that storage and general complexities, before the late 80's, were too limited to handle the requirements for any unified architectures. The cost in storage alone is considerable, which would have made them inefficient and too costly for most, leaving them useless to almost everyone... The standard development/delivery models reflected this in their minimal requirements.

The only way computing will evolve into a more easily unified system is when the performance and storage needs of the customer dicatate that implementation move to a lower, faster, bigger and cheaper level. Interoperability will come as a side-effect of making a profit. It makes no sense to make suicide by self-deprecation a goal.
You mean; when pigs fly, right? The reality is the only ones interested in the projects (who are paid, anyway) are no where near the general requirements for the ultimate solution. In the cases of Semantic ideals, simplifying end user requirements, etc., IMHO, they are all barking up the same old dead tree... Nobody, in their right mind (anyway), would take on the project because of its totality and unimaginable complexity. Or, one could say, because of the requirements for a purely simplistic and related idealistic nature for both the design and groundwork behind the scenes. (I know first hand, I've been searching for active projects for a long time and researched it for far too long. The solution is dead simple but massively time consuming, to the point I haven't even tried starting myself...)

So the evolution metaphor holds better still. Improvement and optimization only take place to fend of death.. No pain, no gain; this time meaning that a comfortable existence does not stimulate progress. Why do you think that the greatest leaps are made while nations fight for their very survival?
You point out the greatest problem with corporate culture and still manage to imply humans will survive, bravo. (I'm reading a bit far into it, but hey...) The theoretical ideas impart few limits to the progress of humanity, except those imposed by the society at large. As for why the greatest leaps, because no one will deny the freedom of progress! (Survival is more important than industries or anyones' mundane lifestyle... Something to think about.)

I think a '2' is only warranted if my above post isn't reflected upon. But hey! Whatever!
You caught my interest but rubbed it the wrong way, best of luck to you next time...

--Singularity means to be infinitely connected. Who's up for working on one?
[ Parent ]

huh? (2.50 / 2) (#12)
by delmoi on Fri Apr 27, 2001 at 04:04:48 PM EST

Returning to the evolutionary metaphor for the moment... Computing is nearing a hard limit of performance and storage. Universal interoperability will not be achieved before this limit falls to quantum or biological computing, but it will be achieved. Computation on the quanum level, or biochemical level, will assure a common architecture upon which to build compatible systems. After all, the lower you go, the fewer differences you have to make use of.

Huh? Why couldn't you say the same thing about electronic curcuts. All computers use the basicaly the same technology now, as far as hardware goes. We just put it together diffrently. The same will most likely be true of newer technologies
--
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
Don't gloss over the hard stuff (4.75 / 8) (#8)
by pos on Fri Apr 27, 2001 at 11:59:29 AM EST

I feel like this is how every open source project gets started...

"There are too many ways to do this. I know: I'll build a new system that adds abstraction and blah and blahblah. Then every os will use it and it will be common across distros."

The problem is that in reality you've just added another way to do it.

The fundamental abstract process of installing software is _always_ the same. You locate the software, download it, and then install it. You recursively apply this formula to the software's dependencies. Voila! Software installed.


Of course, this is the easiest part of the whole problem. A 10 line perl script could do this; it would be cross platform too!

The hard part is dealing with: the existing infrastructure of an OS, software developers that don't use your system, software that must be compiled and installed, software developers that are dealing with stable and unstable code, broken installs, recursive dependancies, bad configurations, etc...

As a user, it makes sence to say that you don't want to be bothered with all the stupid details of installing and downloading and whatnot. As a developer, you would say: this is a really hard project with lots of subtle problems. Perhaps you can try to bring some parts of your idea, such as service discovery, to an existing system. Perhaps apt-get or dselect would have a functional link with KDE's konqueror so that when you click on an unknown file, dselect could come to the rescue.

I would suggest thinking evolution not revolution.

-pos

The truth is more important than the facts.
-Frank Lloyd Wright
FYI (2.66 / 3) (#18)
by kubalaa on Sat Apr 28, 2001 at 01:49:54 AM EST

Actually, on Debian unstable at least, you can click on a deb and it will install it for you. (I've only noticed this from w3m and konqueror) Of course, most of the time you can just apt-get.

[ Parent ]
eh (4.16 / 6) (#11)
by delmoi on Fri Apr 27, 2001 at 03:52:28 PM EST

We'll just end up witha a bunch of incompatable abstractions (Java and .NET anyone?)
--
"'argumentation' is not a word, idiot." -- thelizman
Unlikely (4.40 / 5) (#13)
by k5er on Fri Apr 27, 2001 at 04:35:20 PM EST

On one hand you have those that want choice. Then on the other hand you have those who want everything to work the same and be easy to use. I don't think that having both is possible.

Although I am a big fan of Star Trek. It is still fiction. In reality. Different hardware runs different software, and it takes time to learn about each. An expert in Windows, who jumps on a *nix box for the first time is not gonna easily hack and retrieve data like aliens in Star Trek.

Its like saying, I am made from DNA, and so is an aligator, why can't we just mate and get along.. Same reason, different hardware (genitals)and different software (DNA) configurations.

Although some interoperability may be possible, these machines are designed from the ground up to accomplish different tasks, and although emulation is possible, you take a major hit in performance.

Long live k5, down with CNN.

Klingon Software (4.28 / 7) (#15)
by Osiris on Fri Apr 27, 2001 at 04:59:00 PM EST

In Star Trek a program written on Klingon hardware in the Klingon language can destroy hardware developed across the universe.

That is because Klingon software does not coddle the weak



Klingon Porgamming (2.00 / 2) (#24)
by Morn on Sat Apr 28, 2001 at 10:05:35 AM EST

Sometimes, a Google search can really make you worry...

[ Parent ]
Hmm. (4.83 / 12) (#16)
by zephiros on Fri Apr 27, 2001 at 07:53:57 PM EST

What a great idea. Wonder if anyone is working on anything like that right now. Know any links we could check out?
 
Kuro5hin is full of mostly freaks and hostile lunatics - KTB
Not Related (1.50 / 2) (#17)
by jonnyfantastik on Fri Apr 27, 2001 at 09:29:29 PM EST

All of the links you posted have to do with the Semantic Web. Ontologies and stuff are only marginally related to Semantic Computing which really just needs XML and a few other props.

[ Parent ]

Words (4.33 / 3) (#20)
by zephiros on Sat Apr 28, 2001 at 06:15:38 AM EST

All of the links you posted have to do with the Semantic Web. Ontologies and stuff are only marginally related to Semantic Computing which really just needs XML and a few other props.

Computer ontologies are only marginally related to semantic computing? I wonder if I can get a refund on this dictionary, as it appears to be defective.

Building applications with the level of genericity you're talking about is difficult, for many, many reasons. I offered a few pointers to current work in that field. If you still want to press ahead with coding up an ultimate universal modelling language that represents all possible functionality available on any platform, by all means don't let me deter you.
 
Kuro5hin is full of mostly freaks and hostile lunatics - KTB
[ Parent ]

Worse is Okay? (4.00 / 3) (#22)
by jonnyfantastik on Sat Apr 28, 2001 at 07:55:25 AM EST

It's hard so we shouldn't do it?

I'm not sure if that's wise advice. And I'm not talking about building generic applications, I'm talking about definining common semantics for common computing tasks. For example, the following algorithm should always work when installing software.

void Software::install() {
// make sure it's not installed
if (isInstalled(getIdentifier())) return;

// make sure this isn't an update
if (isInstalled(getIdentifier()) == -1) update();

// install dependencies
List deps = s.getDependencies();
for (Iterator i = deps.begin(); i != deps.end(); ++i) {
(*i).install();
}

// download the software
download();
// install it
doInstall();
// update db
isNowInstalled(getIdentifier());
} Note that there is nothing 'generic' (in the sense that you mean it) about this code. This code is simply abstracted. What each method actually does varies. The method doInstall(), depending on the operating system and version, might install an rpm, dem, or stuffit archive. The methods isNowInstalled() and isInstalled() are simply names -- each operating system is free to implement them however it sees fit. Abstraction does not force everybody to use the same technology, it forces everbody to obey common semantics.



[ Parent ]

Flame (1.00 / 4) (#23)
by tkatchev on Sat Apr 28, 2001 at 08:20:44 AM EST

Dude, learn to code.
The pseudocode you posted is severly
broken.

Sorry. I guess your plans for world domination
will have to wait while you detour and learn
some extremely basic programming.

(Sigh. Anybody else tired of arrogant
know-nothings who are ready to teach the
whole wide world out there how to live?)

   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

hrm? (4.00 / 2) (#26)
by delmoi on Sat Apr 28, 2001 at 02:19:56 PM EST

What's wrong with his code, asside from some strange semantics for determining if the current node is an update (return -1 if a previous version is installed?). Maybe he got the syntax for using STL iterators wrong, but if it's only supposed to be psudocode.....
--
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
Re: Worse is Okay? (5.00 / 1) (#30)
by zephiros on Sun Apr 29, 2001 at 03:33:43 AM EST

It's hard so we shouldn't do it?

It's hard, so we shouldn't attempt to brute force it.

I'm talking about definining common semantics for common computing tasks. For example, the following algorithm should always work when installing software.

Fundamentally disagree. By locking all systems into a specific methodology for handling common tasks, you stifle innovation. Of course, this assumes you could even get all software developers to rewrite their products to support this standard. And that, in turn, assumes you could get any sort of consensus on how to perform these tasks. Sure, for "install this software," the task is simple. Let's try "draw this window" or "authenticate with the network."

Abstraction does not force everybody to use the same technology, it forces everbody to obey common semantics.

Which, in turn, forces everyone to expose identical functionality in their software. Let's pretend for a moment that dloo got enough funding to write a complete OS. In this OS, software is retrieved and assembled on the fly, based on what functionality the user attempts to access. This sort of operating system would have no concept of "installing new software." In order to stay compatible with your model, the authors would have to change their OS design to support your concept of software as a finite series of distinct packages.
 
Kuro5hin is full of mostly freaks and hostile lunatics - KTB
[ Parent ]

Ever heard of an API? (5.00 / 1) (#44)
by MostlyHarmless on Tue May 01, 2001 at 03:55:32 PM EST

This may be a bit of a flame.

What you're describing is essentially a standard API to be used across platforms. Each operating systemn handles the details of the functions you've described, but it must describe those functions. This is nothing new; it dates back to POSIX. Once those functions are implemented, your pseudocode is the only obvious way to call them.

Even so, your package system has issues hidden by the layers of abstraction. A lot of work goes into GetDependencies() that would change according to the platform (as others have said elsewhere in this discussion); in addition, the system also needs a rollback mechanism and a way to handle broken packages.

If the RPM and DEB teams were able to combine their databases, they would, as this would be beneficial to both teams. The interoperability problems lie far deeper than your described algorithm.
--
"Nevertheless, that is the theorem." - Tom Stoppard
[ Parent ]
XML (3.25 / 8) (#21)
by Shren on Sat Apr 28, 2001 at 06:43:31 AM EST

He said the cursed word, "XML". -1 from me. Wait, it's too late to vote down. Damn! What time is it? Where did the sun come from?

XML. It looks like HTML but it's not, it's easy for computers to read except it isn't, it looks human readable but that's really only an afterthought, it looks human editable except that you can't, and it is the foundation for another way to abuse port 80. I cannot bring myself to be impressed.

Huh? (3.00 / 9) (#25)
by delmoi on Sat Apr 28, 2001 at 02:11:45 PM EST

How is XML not human editable?
--
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
What the hell? (4.00 / 1) (#27)
by delmoi on Sat Apr 28, 2001 at 05:22:23 PM EST

ok, 3 people have given me 1s, yet no one has answered my question. I've written valid XML docs by hand, so, what the hell?
--
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
human editable (2.00 / 1) (#38)
by Shren on Mon Apr 30, 2001 at 05:24:09 PM EST

Human editable essentially means reasonably resistant to human error. In HTML, you can drop tags, add characters, forget closings, and all you'll get is a slightly funny appearance. But, try typing in a couple of k XML for input into a database. You'll be willing yourself to die within 30 minutes.

[ Parent ]

wrong (5.00 / 1) (#41)
by Biff Cool on Tue May 01, 2001 at 10:10:47 AM EST

So is source code human editable?  How about config files?  Those at least as open to human error as XML.  XML is alot easier to edit than Perl, or opening a dBASE IV file in notepad.

Also why would you be writing 2K+ of XML for database input instead of using a front end?  If I were doing 2K of dataentry by hand in ANY format I'd be willing myself to die.  Try writing 2K of Tab-Delimited format sometime.  It's not much better.


My ass. It's code, with pictures of fish attached. Get over it. --trhurler


[ Parent ]
hmmm (2.00 / 1) (#43)
by Shren on Tue May 01, 2001 at 01:49:21 PM EST

So is source code human editable? How about config files? Those at least as open to human error as XML. XML is alot easier to edit than Perl, or opening a dBASE IV file in notepad.

Source code is human editable. It is both generally forgiving on where you put the white space and has errors when you do make a mistake that are quite readable.

Also why would you be writing 2K+ of XML for database input instead of using a front end? If I were doing 2K of dataentry by hand in ANY format I'd be willing myself to die. Try writing 2K of Tab-Delimited format sometime. It's not much better.

So are you agreeing with me that XML is essentially crap and doesn't have any advantages over, say, tab delimiting? I don't see where you're going with this.

[ Parent ]

Validators (5.00 / 1) (#46)
by Biff Cool on Wed May 02, 2001 at 11:52:49 AM EST

Source code is human editable. It is both generally forgiving on where you put the white space and has errors when you do make a mistake that are quite readable.

Sometimes source code throws a readable error, but that's only because the compiler is validating it first.  If you run an XML doc thru an XML validator, you'll get warnings/errors for whether your doc is well-formed/valid, just like with source code.

So are you agreeing with me that XML is essentially crap and doesn't have any advantages over, say, tab delimiting? I don't see where you're going with this.

No I'm saying that XML, just like tab-delimited, wasn't meant for you to be hand-typing a database with, there are alot of uses of XML, database exports are just one of them.  Even in the case of just dumping a database, with XML you can store field info in the document.


My ass. It's code, with pictures of fish attached. Get over it. --trhurler


[ Parent ]
Absolutely! (none / 0) (#29)
by kimbly on Sat Apr 28, 2001 at 07:15:13 PM EST

Poor port 80. It's probably feeling somewhat distended, what with all the kludges that have been rammed through it.

[ Parent ]
XML is (5.00 / 2) (#31)
by moshez on Sun Apr 29, 2001 at 07:00:59 AM EST

XML is not good or bad, and certainly not "a way to abuse port 80" (for really abusing port 80, just do IP-over-HTTP. And anyway, the really fun abuses are of port 443, nudge nudge, wink wink, know what I mean?

XML is a standard way to represent trees which contain ASCII data as streams. It's quite useful for that, and not useful for anything else...

[T]he k5 troll HOWTO has been updated ... This update is dedicated to moshez, and other bitter anti-trolls.
[ Parent ]

XML (none / 0) (#39)
by Shren on Mon Apr 30, 2001 at 05:24:47 PM EST

XML is a foundation for SOAP, which (as I recall) shovels executable code and data over port 80.

[ Parent ]
So? (none / 0) (#40)
by moshez on Tue May 01, 2001 at 03:52:31 AM EST

SOAP also mandates that it uses 8-bit characters. Are you going to claim 8-bit characters are evil too, because they allow you to shove RPC through port 80?

There is an existing standard for IP-over-HTTP. That means you can shovel any protocol through port 80. That doesn't mean it's dumber -- it means firewalls assuming port 80 is safe is idiotic.

And you really missed the comment about port 443, did you? Port 443 is reserved for HTTPS -- which means the firewall is very likely not to have any idea what is passing. People should realize that doing this is not really secure, and should just stop.

[T]he k5 troll HOWTO has been updated ... This update is dedicated to moshez, and other bitter anti-trolls.
[ Parent ]

hmm (none / 0) (#42)
by Shren on Tue May 01, 2001 at 01:44:47 PM EST

we both think SOAP is bad, right? So what are we arguing about?

[ Parent ]
SOAP is not Bad (none / 0) (#47)
by moshez on Thu May 03, 2001 at 05:20:38 AM EST

No, SOAP is not bad. Well, certainly not because it uses XML/HTTP. A firewall that tries to prevent breakins by only allowing incoming connections to port 80 is inherently limited. SOAP just shows the futility. Firewalls can only work when there is co-operation from within. Part of the co-operation is "don't run SOAP servers/clients". Another part of the co-operation should probably be "don't run IP-over-HTTP".

[T]he k5 troll HOWTO has been updated ... This update is dedicated to moshez, and other bitter anti-trolls.
[ Parent ]
Human-Readable? Who Cares? (none / 0) (#45)
by craser on Tue May 01, 2001 at 05:37:04 PM EST

I know exactly what you're talking about. For a log time I just didn't see anything to like about XML. But a little experience with it (just a tiny taste) has shown me a few things.
it's easy for computers to read except it isn't,
Not sure where this is comming from. I wrote a little XML parser as an undergrad a few years back, just for fun. I skipped the DTD authentication, etc. The thing was pretty braindead, but parsing? Not a problem.
it looks human readable but that's really only an afterthought, it looks human editable except that you can't
Exactly. XML was never really intended to be human-readable, or human-editable. As the mantra says, it's a way to format data in a language- and platform-independent way. It's glue to let my C & Oracle talk to your Java & MySQL.

-chris

[ Parent ]

Allow Me to Laugh (4.50 / 4) (#32)
by moshez on Sun Apr 29, 2001 at 07:25:54 AM EST

Software Installtion:

This is one of the most potent examples I can imagine. Why is it that installing software is so hard and so different from system to system? This makes absolutely no sense. The fundamental abstract process of installing software is _always_ the same. You locate the software, download it, and then install it. You recursively apply this formula to the software's dependencies. Voila! Software installed.

Oh? You think? What about the part where it needs to decide which of possible dependancies to choose? (I need a mail server. Which one should I install?) What about the part where it asks questions of the user? (Should I connect via SMTP directly or is there an SMTP server I should use? What is the IP? Do I need to authenticate in some way?) What about cases where you need an unsupervised install? Is there way to share answers between several programs? What kinds of questions is allowed? How to phrase the questions so they can be asked in a multitude of user interfaces? How do we translate them into the user's language?

Those were of course the easy parts. How to deal with multiple, competing sources for Ids? How to comparse version numbers to see if a versioned dependancy is satisfied? How do we solve conflicts?

As someone who is a part of the Debian project, I happen to know that these are the questions we have to struggle with everyday. Debconf, apt-get and apt-cache and others are among the answers we have given. It is not perfect -- and more importantly, it requires enormous amounts of man power to take useful pieces of software and integrate them into the whole that is Debian.

[T]he k5 troll HOWTO has been updated ... This update is dedicated to moshez, and other bitter anti-trolls.

I don't see why everybody's against... (2.00 / 3) (#33)
by costas on Sun Apr 29, 2001 at 09:13:46 AM EST

...this idea. I've had the same thought --more or less-- myself. I donot see that this is an unsolvable problem. Computer software is a finite realm of solutions: some programs offer services (like a deamon in Unix or an NT service) some are executables. Some take command line arguments, some have configuration files. Yes, the parameters themselves and the software's capabilities differ wildly from software to software but not by much.

If XML can help different ERP systems to talk to each other, when those systems are from different vendors, are on different platforms, and often are implemented by companies in wildly different industries, using very different business processes, we can surely abstract the OS enough, so that Apache can install itself on Windows as well as Linux with the same initialization/configuration file.

memigo is a news weblog run by a robot. It ranks and recommends stories.
hmmm (5.00 / 1) (#35)
by charliex on Mon Apr 30, 2001 at 02:08:59 PM EST

me: hey lets write this new whizzbang installer that works cross platform and allows one point of entry. Its less to maintain and more cost effective

manager: well the current installer seems to be working for the 500,000+ clients we have, whats the plus..

me: well apparently it'll allow viruses to work on alien computer systems.

manager: i'm going to write up my expense reports, oh and theres been a month dropped from the deadline.

me: can i go home yet?


standards or semantic computing (none / 0) (#36)
by Pink Daisy on Mon Apr 30, 2001 at 02:10:04 PM EST

Seems to me you are looking for standards, not semantic computing.

I can already install new software with one click. For example, to upgrade my OS, I click "yes" when Windows says there is a new critical update available. For Linux it's a bit harder; I type apt-get update; apt-get upgrade.

To install other software, it's pretty simple. For ICQ, I download it and execute, and hit the "next" button a few times. For Linux, apt-get install licq works very well. Unless you want kde integration, of course...

The standards for what you want are there, and in use. The difficulty is that there are too many of them, and not everybody obeys them anyway.

For semantic computing as you describe, the requirement is that I have some similarly simple method, but that it works on all platforms. Debian, Red Hat, SuSE, Windows 2k, even Macintosh. The only thing I can say is the program name, so as to distinguish between ICQ, licq, and kicq.

You can see how it would be very difficult for a standard to live up to that. Even if you could localize the system specific configuration (apt-get and the wise installation wizard seem to do that pretty well already), you still have to make sure to fetch source or binaries that work on your system, even if they aren't available. Not a trivial task!

So I think your goal is very unrealistic as long as we rely on native binaries. Even source isn't a good medium, as ports to all desired architectures are likely non-trivial. Someone will probably solve this some day, but it will take more than XML and it will take more than Java, and probably more than XML and Java put together.

Heh heh, never trust "Science Fiction" (5.00 / 2) (#37)
by cable on Mon Apr 30, 2001 at 04:34:53 PM EST

Remember "Independence Day" and the Powerbook that connected to an alien mainframe, uploaded a virus (with the command "upload virus" issued in English to the alien's mainframe system), and then help to caused the destruction of the mother ship?

How about "Alien", "2001", and others that had CRT Monitors so bright that the words were projected onto the user's faces? "No! It is too bright, turn it off, turn it off! Ahhhh! Its melting my forehead!"

Or how about all those alien races that are able to take over "Voyager's" computers. Not even from the same part of the galaxy. At least the Klingons could capture a Federation vessle, study it, and learn how security and systems works, being in the same galaxy and having more than one enemy ship to capture. Or maybe they just ran the 25th century version of Crackerjack or whatever the Script-Kiddies use? ;)

Ah but they are writers, not IT workers, they have no idea how a real computer system works.

Just like in "Demolition Man", Simon Phoenix typed in the word "override" to override a graffitti removal system's safetys. Yeah, right, like that'll work! Also works great on ATMs and Phone Booths? ;)

Or the Role Playing Game Traveller and the Evil AI computer Virus that also infected any sort of equipment, computer, ship, anything that used a computer. Even a simple computer watch or laser rifle. Someone forgot to tell the writers that they all use different operating systems, even the alien races, just that maybe in the future they all use the same OS for everything? Or standards that allow a virus program to replicate and adapt to new systems?

------------------
Only you, can help prevent Neb Rage!

Semantic Computing | 47 comments (41 topical, 6 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!