@ShadesOfGrey

Well, first of all, I recommend reading what I wrote in the thread where this post of yours was originally posted, before it was moved here by the moderator.

Secondly, I find your theory that Amiga Inc. would only pursuing the lawsuit against Hyperion for "stopping" AmigaOS4 not very plausible. It's quite evident that they do not want to just put an end to Hyperion's development and marketing of AmigaOS4, they want the source code. They don't need the source code if they just want to put an end to Hyperion's development and marketing of AmigaOS4.

Now, of course you may argue that they want it to secure their IP for increasing the value of their IP portfolio or whatever. However, considering the money they are spending on the lawsuit and the $2 million they offered to settle out of court, I doubt the source code would increase the worth of their IP portfolio that much. Surprisingly enough, it seems more like money is of less concern for Amiga Inc. right now. Not sure wether that is a good thing but still...

It's also not completely unrelated that they have now hired Jamie Krueger and that court documents reveals that they have also offered certain AmigaOS4 developers to come work for them instead of Hyperion (wether they accepted is unknown). It seems clear to me that they have something cooking, something related to AmigaOS4.

BTW, your argument that Hyperion's "inability to pay its contractors is a direct result of AI's sabotage" can just as well be applied the other way around. Maybe Amiga Inc. wouldn't have ended up in the financial bind that they did a few years back if Hyperion had delivered on time as they agreed to by the contract? Something which might also have prevented alot of their infamous track record that you mentioned.

Besides, what did Amiga Inc. do to "sabotage" AmigaOS4? If you're refering to that they didn't give Hyperion a license to develop for more hardware, you have to remember that they didn't complete the development for the hardware they did get a license for until very recently. What difference would it have made if they got to develop for any hardware they wanted, are you saying other hardware would be faster to develop for or something?

And once again, Hyperion drafted the contract themselves. They were as aware of the terms as anyone could be. To keep blaming the terms of the license agreement that they agreed to really isn't an excuse for anything.

Last edited by samface on 30-Jan-2008 at 08:16 AM.

_________________
Sammy Nordström, A.K.A. "Samface"

MINDRELEASE.net - The Non-Commercial Network of Digital Arts.

Samworks D & C - Professional Web Development (in Swedish)

@ShadesOfGrey

Quote:

As much as I'd really like to see OS4 go somewhere, at this point I think both AI & Hyperion have jumped the shark.

I agree completely. There was a time window when AmigaOS could have have grabbed itself some market share in the mobile space, ironically back in 2000/2001 when Amiga Inc was pretending Classic didn't exist and backing Tao. At the time Linux was too immature to use on most mobile devices, Windows CE was a joke, and hardware was still weak enough that having a lightweight OS would have made a big difference. I think Amiga Inc did eventually realize this (the proof is in the Arctic device), but by that time the window was starting to close. Now with the lawsuit, which has essentially stalled development until it's over, OS4 as a "serious" OS is pretty much dead. The only chance it has is as a retro hobbyist OS for people who appreciate simplicity and don't mind giving up some modern features in order to get it. If it gets marketed correctly, it could sell a few tens of thousand copies. Of course, the odds of that happening are pretty much zero, which is why I'm watching the FPGA crowd quite closely these days. OS4 is dead, long live OS1.3...

As far as OS5/AA2 is concerned, it's going to get squished between Qtopia on the one side and Silverlight/Moonlight on the other. I've never used Qtopia but Nokia are no fools, and Silverlight allows one to do 3D accelerated graphics with the simplicity of HTML. Thanks to Mono and Moonlight, you'll be able to write code on any PC, Mac or Linux box and it will run on anything from desktop to handheld running Windows, Linux or OSX. And it's designed to run on a browser, so developers are encouraged to keep bloat low. AA2 will have to be pretty stunning to compete with that on technical merits. If that weren't enough, Amiga Inc will also have Nokia's and Microsoft's marketing departments to contend with.

Last edited by CodeSmith on 30-Jan-2008 at 09:48 AM.

Sorry for the short delay, found a couple typos I wanted to fix first.

@samface

In reference to

this post and this one.

Quote:

And please stop blaming Amiga Inc. for Hyperion's doings. Things would probably have been very different if Hyperion had delivered on time as they were bound to by the contract and all rights handed back to Amiga Inc. when they payed. Now that Hyperion have delayed completion by several years, violated the agreement and refused to deliver AmigaOS4 to Amiga Inc., why in god's name would Amiga Inc. grant them any license to develop for more hardware? In fact, it wasn't until recently that they finally fulfilled their obligations to release AmigaOS4 for the hardware devices mentioned in the original license agreement, eg the AmigaOne AND PPC equipped Amiga1200/4000's. It wouldn't be very appropriate to demand a license for more hardware to develop for while they still haven't completed their current undertakings, wouldn't you agree?

IIRC, Hyperion wasn't obligated to specific dead line. They were expected to make a "best effort" attempt at a specific dead line.

Now, if you believe Hyperion, both the company and some of its contractors (The Friedens). AI did not supply them with the source for OS 3.1 and or the two subsequent updates (3.5 and 3.9). Hyperion had to obtain these sources through other means. This lead to a delay in getting started. AFAIK, AI have never disputed this. If I'm wrong, well sue me . Seriously though, if you can provide a specific reference where AI refute this, I'll reconsider this 'fact'.

As for the buy-back clause. As far as I can tell, AI admits they did not actually pay the full amount. While there were other funds transfered from AI to Hyperion. Hyperion's position is that AI can't simply credit those funds toward the buy back if they weren't specifically intended for that purpose. To sue your own analogy/metaphor.

Quote:

As a metaphor to easier describe what this case is about; your mechanic might decide keep your car until you pay for the repairs you hired him to make, but would it be theft if you decide to take legal action to get your car back when you have paid and the mechanic still refuses to give you your car back? It doesn't matter if it turns out that you paid too late or whatever else reason their might be for you to loose your rights to that car, it's not to steal to excercise your rights to a fair trial and any outcome in a court of law is never illegal.

Lets you send your car into a mechanic for routine maintenance. Then pay him a partial sum toward that maintenance; with the proviso that you want additional work done, separate from that maintenance. Lets say install a racing transmission. You pay him to obtain the parts and do the labor. Lets say you even over pay him for that work, given the market value of the parts and labor. However, that's the price you agreed upon. When you finally come to pick up your car, you don't pay the full amount for the original maintenance. Instead you say, "Well, since I paid you so much for the after market parts and the labor to install them, lets just call it even." At this point it's up to the mechanics discretion to accept or decline this deal. Even if it appears an insignificant amount. Should the mechanic simply hand over your car???

The fact is yes. But that's because we're talking about cars. There are other avenues of redress when it comes to physical property. However, In the case of intellectual property, things are more tricky. Hyperion's contractors have in fact added substantial value to the 'original' AmigaOS. Those contractors are entitled to compensation for those additions or to withhold them outright (based on waht I undestand of the contracts they signed with Hyperion by its contractors). Now, you can say, "Well, it's still down to Hyperion! They're the ones who have to pay their contractors!" Well, what if Hyperion can't pay? Which seems to be the case. What happens then?

One possibility is you could add, "Amiga Inc. is even willing to pay those contractors individually for their IP!" One thing the contractors can say is, "Show me the money!" So far, AI hasn't been all that reliable in meeting their financial obligations. No matter which incarnation of McE and Co. your talking about. But lets say that AI is solvent and has always been so (despite McE testimony) Another is, what kind of deal would AI be offering? Now, I presume that AI wants to buy the IP outright. That's because OS4 for them is a dead end. AA2 is what they're banking on and it has nothing to do with the original AOS. Perhaps this doesn't sit well with the contractors? Perhaps, even though Hyperion isn't paying them, the terms they came to with Hyperion are far more attractive then what AI is offering? Perhaps they want to use their IP toward future projects, not pertaining to AI's endeavors? Who knows? It's also conceivable that AI has no intention of negotiating with the individual contractors. They may be hoping to win OS4, lock, stock, and barrel from Hyperion without the need to pay the contractors. After all it would fall on Hyperion to pay those debts if the buy-back clause can be invoked. Those contractors just get shafted.

Or to put it your way:

Quote:

If they want to lock it up in a vault for collecting dust over the next couple of decades, it's in their right to do so with whatever they own.

As to your comments concerning Java, .Net and hypervisors.

I'm not sure if your speculation on the use of Amiga 'technologies' refer to OS4 or AA2. Regardless, your understanding of hypervisors appears falwed. When you say "It's applications with "built-in" hardware virtualization technologies that enables the application to be run on virtually any computer, completly independant of the OS." First, what do you mean by "any computer"? Keep in mind that your hardware has to support virtualization and the hypervisor must act as or be layer above the firmware of a computer. Hypervisor don't magically work on "any computer". Second, hypervisors can not run an application completely independent of the OS... At least not how you seem to describing it. How can a hypervisor run a Windows app without Windows installed? Does it magically emulate the entire Win32 API? No. Windows applications run within Windows, which in turn runs within the hypervisor. Now there are things like KVM or HyperSpace. Since both of these approaches are Linux environments (KVM) or based on Linux (HyperSpace, reportedly); conceivably, you could run any x86 based Linux application (so long as all dependencies were accounted for) within these environments natively. HyperSpace, BTW, does not actually allow this, it has a set set of applications.

Now perhaps you were merely generalizing. If that is the case, I think you should be careful you don't overgeneralize.


First a disclaimer. I'm not an expert in Java. I have written a few simple applications for my own personal use. I've also used, to a very limited extent, JNI (and when that failed ) OSS JNI libraries to complete those applications.


As to your comments about Java not being capable of acting as a hypervisor, I respectfully disagree. Or I at least would put forth a hypothesis on how Java could be a hypervisor. In fact, it is possible that Java could be the basis for a multi-platform hypervisor. To simplify, I'll use the commodity x86 platform. Integrate a Java processor (they do exist). Write some Frimware that can boot strap the JVM and tell it what platform it's running on/with. Then have the JVM invoke the necessary JNI routines to create the proper environment for guest OSes to run within.

Obviously this is a pretty dirty way to get Java running as a hypervisor. But I'm just pointing out that your argument against Java is not bulletproof. As for .Net. I don't have enough familiarity with it to say if this were possible for .Net or not at all.

Last edited by ShadesOfGrey on 30-Jan-2008 at 01:57 PM.
Last edited by ShadesOfGrey on 30-Jan-2008 at 01:56 PM.

_________________
Unless otherwise explicitly stated, this message is not meant to affirm nor deny, defend nor offend any faction within the 'Amiga' Community.

@ShadesOfGrey

Well, I really don't know what makes you believe, that JAVA has any impact on desktop apps at all. As for mobile platforms, then yes, but once again - ask someone how cool it is to develop for JAVA for mobiles and how "compatible" those releases are even with single vendor as Nokia. Besides that, Sun pretty much announced, they will further pursue only the "big" JAVA.

As for Silverlight, that might be better, but doesn't it need all the .Net crap? How big is .Net 2.x? If the "environment" comes with your device, it is OK, if you will need to upgrade, well then, you might be in trouble, if you want to do it online.

So, my intention is not to defend some mysterious AA2. It is not based on Intent after all, so what actually is it? I think that Bill would make the best decision to partner Carl Sassenrath and base AA2 upon REBOL 3 - still a thing under 1MB of storage. Good for mobile level apps. Well, you will not use it for anything like Doom clone or to create MS Word, but R3 goes the AA2 route anyway.

In something like 5 years, my prediction is, that there is no point in OS at all. So what is OS4 in that five years anyway? Who will care and why? Browser becomes one big containers for other technologies. OS will be more like a firmware - you need it, you know it is there, but who cares about how it is called or what exactly it does, if it does that efficiently enough.

Only content will matter.

Just a few random personal thoughts;

I found various comments I'd made on certain sites the other day (from about 2001/2). All of which were in support of Amiga, Inc (Bill, Fleecy etc). I noticed someone had labeled me an "ignoramus" and "blind follower" - I have to say, I was a bit.

I thought the whole concept behind the AmigaDE/Amiverse etc (remember that term? Amiga had a whole lot more detail on their site back then - see below) was a great one. Actually, I thought it was entirely logical and a great future goal. A digital content layer, which would sit on top of any OS, but primarily AmigaOS4.x as an efficient and tidy host.

I pretty much feel Amiga (as a company) totally missed the boat and the Amiga as a platform, would need a miracle and more to bring it back into the 'mainstream', now.

AmigaOS4 is a wonderful product and since installing it, it has brought back all that excitement and awe I felt, when I first got to sit down and use an Amiga properly for the first time. To me, that's a feat in its own right. Obviously, other outsiders may not 'get' that.

There's a mixture of 'Amigans' who actively use the platform, ex-users who keep an eye on any news, users from years ago who always shed a nostalgic smile when they hear the name and people who have never heard of it, but show interest.

What is OS4 on its own? What does one want it to be, or come of it? I felt the original Amiga buzzwords and 'mission' to be a valid one and one which would have brought the DE and OS4 forwards, but none of us seem to know what their real goals/intentions were.

I shall continue to support the platform as long as I can. To me, that means supporting a product I enjoy using, can use and want to use. That's my bottom line.

I just wish both parties could come to an amiable conclusion. A common goal would be a refreshing change. Come on... *sigh* Life's too bloody short!

(I shall post more soon).

Quote:

Entering The AmiVerse In 1984, the Amiga 1000 burst upon the scene of an unsuspecting world. Such was its revolutionary nature that people only had to use one for a few minutes before they experienced an almost religious shiver down through the soul, as if all the confusion and frustration suddenly went away and everything made sense. The Amiga 1000 was revolutionary because it stepped aside from common convention. It took a fresh, unfettered look at the problems of computing, video, and gaming technology. It worked out the problems, the bottlenecks, the issues, and then solved them in a simple, elegant way. Fifteen odd years later, we've flashbacked to 1983 were traditional technologies and approaches dominate. Advances are now mainly through process enhancements: Faster processors, faster graphics cards, more memory, prettier operating systems, more utilities and functions. Innovation has stalled because there is too much investment in the past to allow the future to profit. Yet the future is there. The volume of digital content is growing exponentially, with the demand for that content not far behind it. Access is becoming ubiquitous, broadband is common. In a few short years, the Internet has gone from being a geek oasis to the place we all go to shop, pay bills, send letters, talk and play. We all want to have our digital kingdoms at our fingertips, available everywhere, at any time, and instantly--and yet we can't. Why? Because what we want doesn't fit into the technology of today. Computers are expensive. Computers are complicated. Computers are frustrating. They were built to handle batch files stored in rigid hierarchies using big applications. In short, the digital revolution has outgrown its computer nursery. To understand the Amiga solution for tomorrow requires a paradigm shift, the acceptance of a certain set of core truths. Otherwise, people will just end up trying to smash traditional ideas against a new model to no avail. AmiVerse Firstly, there is no such thing as a file. All elements are now just digital matter, a stream of zeros and ones. Second, there are no applications. There are just activities that involve producers and consumers of that digital matter. Third, there is no such thing as an operating system. There is merely a set of services produced by service providers and consumed by service requestors. Fourth, these services, producers, consumers and digital matter exist independently of individual physical devices. Now these four core truths may seem bizarre when measured against traditional computing architectures and models, but that is an indication of how our view of the world has been warped to fit in with traditional computing paradigms. In fact, our photographs aren't files, our apples aren't files, and our life isn't a directory structure. We buy wine from a store, we don't need to have a vineyard, a winery and a bottle producing factory to get that wine. Humans have spent thousands of years creating perfectly good models for production, location, manipulation, organization and consumption. The first computers, because of their low power, tied us very tightly to their hardware architectures. That time is now long gone and yet the computer world still holds onto it. Amiga is going to show the world that letting go makes perfect sense. Introducing Ami™ Ami™ is Amiga's solution for the digital world of tomorrow. Ami™ is a set of digital matter (binary) elements that produce and consume services within a logical dynamic context. That context is called the AmiVerse™. It exists almost as a virtual world in which these binary elements go about their business, passing messages to each other, grouping together, co-operating with each other. The user appears as its own element within the AmiVerse, but with the power to create, manipulate and destroy; a digital sorcerer if you will. An AmiVerse™ can exist on a single hardware domain, such as a PC, it can share that domain with other AmiVerses™ or it can be spread out across a matrix of hardware domains. Workstations, PCs, laptops, set-top boxes, games consoles, DVD players, smart TVs and cell phones will all still exist, but as hardware domains (a collection of hardware considered a unit), not as a hardware side of a computing coin. Ami™ decouples the user and developer experience from the hardware foundation. Hardware domains provide hardware services to one or more AmiVerses™, and AmiVerses™ request hardware services but make no assumptions about the location, quality or quantity of those services. Everything is negotiated and brokered dynamically. The AmiVerse™ is a closed environment. It knows everything that is inside, it is responsible for letting new elements and services in, and for letting them out, via the AmiGate™ and an immigration service. As a result, it is completely self descriptive. This descriptive feature extends far beyond content though. Ami™ makes very heavy use of a semantic mechanism. Not only does the AmiVerse™ know what it contains, it also provides a rich set of resources for describing what they can all do, what they are like, and what they require. Description is a key feature of the AmiVerse and is used as the foundation for organization, location, control, and interaction. This is achieved via Vocabularies and Interface Descriptions. In traditional computer architectures, organization is tightly coupled to storage, the typical hierarchy of files and directories within a single filing system. The AmiVerse™ completely ignores that model. It presents a structureless sea of binary elements. Structure and organization comes from throwing questions into the sea and getting back the answers. This querying service is supported by the vocabularies and interface descriptions and uses the concept of sets to process, persist and group. Thus, a user can create a set with the query, "all elements of content type 'gif'" called Gifs, and another set with the query, "all elements of owner 'Timothy'" called MyElements. As a set only contains references, in the form of unique element identifiers called AmiIDs™, a single element can be a member of more than one set. Queries can be static, dynamic, transient and persistent. Instead of some arbitrary hierarchical distinction that allows for only one reference, users can now make associative and relational sense of their digital environment. How they are stored is the business of the persistence service. It is irrelevant to anyone operating within the AmiVerse™. Their concern is that when they have finished with something it is persisted, and when they want to use it again, it is available. By decoupling organization from persistence, the persistence service can now concentrate on doing a good job of persistence and retrieval intelligent caching, retrieval statistics, combining elements together, using multiple filing systems with each one tuned to particular types of element (large, small, streaming, static, dynamic etc). There is no such thing as an application in the AmiVerse™. Instead, users perform activities. They may fetch a piece of paper, to write an essay, an email, or draw a picture. They may listen to some music or play a game. They may decide to build an application. Ultimately, all of these activities break down in service requests and provisions. A typical interaction might see an object ask the AmiVerse™, via the service broker, for a printing service or a 3D service, or an Internet connection service. The service broker then queries its lists of service providers, considers the current state of the AmiVerse™ plus any special request directives, and then hands the answer, a set of none, one or more possible service providers. The object then picks one and starts dealing directly with it, as the service broker steps out of the way. This has just been a small, very high-level description of Ami™, the new girl in town. As you can see, she is both very different and yet very familiar. This is intentional. By escaping from the legacy albatross, we can start to make the digital age work the way people expect it should. When it works the way you think it should, then you work the way you should, and that is what the digital revolution is all about.

It all sounded great, didn't it?

Steve

Last edited by stevieu on 02-Feb-2008 at 01:20 AM.
Last edited by stevieu on 02-Feb-2008 at 01:19 AM.
Last edited by stevieu on 02-Feb-2008 at 01:17 AM.
Last edited by stevieu on 02-Feb-2008 at 01:11 AM.

_________________
A1200T - OS4.0,OS3.9: 603e PPC 200mhz,060 50mhz, 256mb ram, FastATA MK-III, BVision, 160gb,20gb HDDs

A1200 - OS3.1: Blizzard IV 030, 64mb ram, 400mb HDD

OS4.x - Flying the AMIGA flag