Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (joerg)

Bottom

« 1 ... 62 63 64 (65) 66 67 68 ... 86 »

joerg

Re: Want to Purchase DVDRW for A1. Which would you recommend?

Posted on: 2008/7/19 16:20 #1281

Just can't stay away

@Mikey_C

Quote:

Hmmm, so far, from the looks of it, you all agree to disagree - seems like its pot luck so far!

Nobody mentioned bad experiences with Plextor drives yet, but they cost about twice as much (50-60 Euro) as Asus, LG, LiteOn, Samsung, Optiarc (Sony/NEC), etc. drives (25-35 Euro). Maybe it's worth it if you burn a lot of CDs and DVDs, but for most people only occasionally burning a CD or DVD it's not IMHO.
It's best is to get the exact model someone is using successfully in an AmigaOne already, just selecting one by brand isn't, IIRC even some Plextor drives were just relabelled BenQ drives.

Topic | Forum

joerg

Re: Want to Purchase DVDRW for A1. Which would you recommend?

Posted on: 2008/7/18 14:32 #1282

Just can't stay away

@Mikey_C

Quote:

Above says it all, is there a particular model you would recommend? obviously it has to be IDE and internal.

Your recommendations welcome.
(am replacing the internal CDRW because, I found out last night that neither AMIDVD or MakeCD seem to want to work with it.)

With AmiDVD there were no problems at all yet, at least none reported, with LG and Plextor drives. The most problematic ones are AOpen and Pioneer drives, although I got DVD+R working with Pioneer drives it required a special workaround making it slower. On os4welt.de is a list of drives tested with AmiDVD: http://os4welt.de/html/tt/HWListe/Brennen/AmiDVD.html (with the Sony DRU-820a burning CD-R doesn't work, with all other listed DVD burners there are no problems left with AmiDVD AFAIK).

Topic | Forum

joerg

Re: AmiDVD & Dual Layer

Posted on: 2008/7/17 2:21 #1283

Just can't stay away

@Snuffy

Quote:

I usually go with make image. 'Flying' is not IO stable.

It doesn't matter with buffer underrun free recording, and the errors Swoop gets are before writing has started in a part of AmiDVD which is identical for images and on-the-fly burning.

Topic | Forum

joerg

Re: AmiDVD & Dual Layer

Posted on: 2008/7/17 2:13 #1284

Just can't stay away

@Swoop

Quote:

I get the same error using either 8x or 2.4x discs.

Is there anything else I can try?

Since the error codes are no standard ones but vendors specific I have no idea what they mean, but obviously your drive doesn't recognise the 2.4x discs correctly either since the write speed AmiDVD gets from the drive is wrong, it's just the default/max. speed which is returned as well for example if there is no disc in the drive.

Topic | Forum

joerg

Re: Licence

Posted on: 2008/7/11 19:06 #1285

Just can't stay away

@orgin

Quote:

orgin wrote:
@joerg

I read through MPL and APL. Bit too rich for me to get a full gripe of what it all means. Some stuff, like the US government stuff, seems to not fit in there. I hope someone joins in that can read though them and give us some insight and tell us if it can be used to fulfill the Open Amiga ideas.

The details are only interesting for, and comprehensible by, lawyers. The basic ideas are

BSD: No restrictions. Can be used for Open Amiga, but doesn't enforce open source.

MPL/APL: What was released as open source has to stay open source incl. all changes made to it, but it's limited to the individual source files and doesn't add restrictions to other software incl. other source files linked into the same executable or library. Ideal for something like Open Amiga if you want to enforce open source. Except for for coding examples/templates, to make it possible to use them as base for own software without having to release the sources they should use a BSD licence instead.

LGPL: All sources of an executable or a library, even if it's just using a single LGPL function, have to be open source. Doesn't add restrictions to software just using a LGPL library (but only if it's dynamically linked, i.e. an AmigaOS .library or a shared object, everything statically linked with LGPL code has to be LGPL). Usage for Open Amiga is very limited, it could only be used for tools and libraries which are a complete replacement or something new, not for improvements of existing parts since none of the sources can be used in software with another licence.

GPL: Extremely virulent crap which isn't usable for anything, especially not libraries since any software just using the library has to be GPL as well. The Linux kernel has an exception invalidating the most important GPL points, without that all software running on Linux would have to be GPL. May even affect generated data, IIRC GCC has an explicit statement that the code it generates isn't covered by the GPL. If you think it's usable for anything you either don't understand it, or you are as mad as Richard M. Stallman and should consult a psychiatrist immediately

One example for the GPL nonsense on AmigaOS is YAM, it's GPL but violates it by using the non-GPL MUI libraries and classes (at least on AmigaOS 3.x where MUI isn't part of the OS, AFAIK there is an exception for OS parts). GPL software isn't allowed to use libraries with another licence.

Of course there are much more licences, but for the most important parts everything else is just a variant of one of the 4 above ones.

Topic | Forum

joerg

Re: Licence

Posted on: 2008/7/9 3:32 #1286

Just can't stay away

@orgin

Quote:

2. I'm no expert in LGPL so I don't know what it allows and on what level. I know that you can release binary libraries with it, but what about stuff that gets integrated closely with the OS? For example, if we make a patch that adds some functionality to an existing library, can Hyperion then use that code to build a complete non patched library that contains non LGPL code?

No. The LGPL is nearly as evil as the GPL, the only difference it that it doesn't affect software just using a LGPL library, "only" all parts of the library itself have to be LGPL. With the GPL even software using a GPL library has to be GPL.

The only usable licences are BSD ones (changes don't have to be released) and MPL ones (changes in the source files initially released under the MPL have to be released under the same licence, but no other sources of software using them). For example AROS uses a licence similar to the MPL which made it possible to use AROS code for large parts of MorphOS (dos.library, C: commands, intuition.library, gadtools.library, asl.library, commodities.library, diskfont.library, icon.library, locale.library, iffparse.library, ...).

Topic | Forum

joerg

Re: OWB Doduo

Posted on: 2008/7/7 19:22 #1287

Just can't stay away

@VooDoo

Quote:

hmm..I have all SOBJS files..but cant start last update..All the time have info about missing ELF files..

Did you install libjpeg.so?

Quote:

maybe problem is what I have only 256 MB??

No, the executable is less than 50 MB and for the first few pages 256 MB RAM are enough.

Topic | Forum

joerg

Re: OWB Doduo

Posted on: 2008/7/6 17:06 #1288

Just can't stay away

@Chris

Quote:

I hope you don't mean naming them with the version number and creating fs links between differently-named but compatible files?

Different names only for incompatible versions, and no links (at least not in SOBJS:).
On AmigaOS4 there are different directories for shared objects, SOBJS: is used when an executables/elf.library loads them but the linker uses SDK:(Local/)newlib/lib instead, on Unix you only have a single directory for both and need for example a /usr/lib/libfreetype.so -> libfreetype.so.6.3.16 link or the linker wouldn't find it when using -lfreetype, and additionally you need a /usr/lib/libfreetype.so.6 -> libfreetype.so.6.3.16 link since that's the name the executables use (libfreetype.so.6 is the soname of libfreetype.so.6.3.16). If the same names would be used you'd have a SOBJS:libfreetype.so.6 and a SDK:Local/newlib/lib/libfreetype.so with soname libfreetype.so.6 on AmigaOS4 and no links are required.

Edited by joerg on 2008/7/6 17:22:20
Edited by joerg on 2008/7/6 17:25:45

Topic | Forum

joerg

Re: OWB Doduo

Posted on: 2008/7/6 16:46 #1289

Just can't stay away

@hotrod

Quote:

Wow, this new version seems to be rock-stable here so far. Sites that didn't work too well seems to work stable and good now.

It still has serious bugs, for example the ACID3 test crashes because of memory corruption, very likely something is overwriting a too small buffer, which often happened in Blastoise as well, but the updated WebKit fixed a lot of bugs and added new features. ACID3 crashes at the same place on Linux as well - but only with the SDL version, the Gtk/Cairo one nearly passes the ACID3 test and doesn't crash.

Quote:

Yes it's very slow, but that was expected. Thanks!

There are several reasons why it's slow. It's a debug build, it's using libfreetype instead of the much faster AmigaOS4 ft2.library and Doduo doesn't render the complete pages any more but just the visible parts, like the AmigaOS4 port of Blastoise does with the "LOWMEM" tooltype, which of course makes scrolling much slower since it has to render the new parts instead of just copying parts of the pre-rendered page image into the window.
Pages with lots of GIF anims, for example forums with animated smilies, are still very slow, but that's only the case with SDL as well, with the Gtk/Cairo version there is no problem. After I've ported all additional AmigaOS4 features from Blastoise to Doduo I'll check why GIF anims are slow with SDL.

Topic | Forum

joerg

Re: OWB Doduo

Posted on: 2008/7/6 0:04 #1290

Just can't stay away

@Hans

Quote:

Sadly, it still crashes when trying to visit http://demo.silverstripe.com.

Strange, it doesn't crash here.

Quote:

When running it from the shell, I get the following message when trying to visit that page:
Quote:
UNIMPLEMENTED:
(/CS/OWB_Doduo/BAL/WKAL/Concretizations/Widgets/SDL/BCFrameSDL.cpp:53 void WebCore::Frame::clearPlatformScriptObjects())

That should give an idea as to where the problem lies.

No, it's nothing important and you get a lot of similar debug output for all pages, for example I get that one when using "owb http://google.com/" and quitting OWB.

Topic | Forum

joerg

Re: OWB Doduo

Posted on: 2008/7/5 18:18 #1291

Just can't stay away

@Ricossa

Quote:

First, thanks for your efforts. I tryed to install it, but I can't launch it: it keeps saying : required object missing, althouth I verifyed that all the .so where in place.

Unfortunately there is no way to find out which shared object is missing, IIRC using Snoopy doesn't work either. But it's probably libjpeg.so, I though it would have been included in OS4 like libpng12.so, but I just checked it and it isn't.

Topic | Forum

joerg

OWB Doduo

Posted on: 2008/7/5 17:41 #1292

Just can't stay away

A first version of the AmigaOS4 port of OWB Doduo is on my homepage now. Most of the AmigaOS4 addtitions of the OWB Blastoise port are still missing, it's a slow debug build and you should keep OWB Blaistoise for now, but you can use it for testing pages which don't work with OWB Blastoise.

Topic | Forum

joerg

Re: Workbench enhancement project

Posted on: 2008/7/3 21:23 #1293

Just can't stay away

@LiveForIt

Quote:

You forget Linux programs already uses the clib / newlib functions.

The 32 bit functions and data types, not the newlib 64 bit ones.

Quote:

What is mostly required is to get programs that's already uses fopen() fclose(), fprintf() to work whit dos.library 64 bit commands, but this commands seams incompatible.

That doesn't work, changing the standard functions (fopen(), fstat(), ftello(), fseeko(), ...) and data types (off_t, struct stat, ...) to 64 bit would break all existing static link libraries, shared objects and programs using shared objects. The statically linked executables are no problem since the old functions could stay in the interface and new 64 bit versions added at a different offset with the same name, but that doesn't work for executables using shared objects and for libraries, no matter if they are static or shared ones, which only have the names of the missing functions and would use the wrong (64 bit) functions with the old 32 bit data types (32 bit off_t, a way too small struct stat, ...).

Quote:

fopen returns a int or FILE, but Open() in dos returns BPTR, if you have idea or example on how you can mix commands then please, write some examples, or else large quantizes of code needs to be rewritten to only use 64bit commands in dos.library.

You can't mix C library and dos.library I/O, but you have to change the code anyway and there is no big difference if you change it to use the 64 bit C library functions (fopen64(), fstat64(), ftello64(), fseeko64(), ...) and data types (_off64_t, struct stat64, ...) or the dos.library 64 bit functions (IDOS->FOpen(), IDOS->ExamineObject(), IDOS->GetFilePosition(), IDOS->ChangeFilePosition(), ...) and data types (int64, struct ExamineData, BPTR, ...).

Topic | Forum

joerg

Re: Workbench enhancement project

Posted on: 2008/7/3 0:03 #1294

Just can't stay away

@LiveForIt

Quote:

Well your wrong there you have full access to DOS.library 64bit commands.

AFAIK the last public SDK only included the 4 (Get|Change)File(Postition|Size)() functions but not the new directory scanning functions yet and ExAll() can't return file sizes > 4 GB - 2 bytes, without a new SDK you have to Open() a file and use GetFileSize() to get the real size.

Quote:

but we do not have working clib and newlib functions for 64bit reading and writing.

so you can write your own software thats easy, but its hard to port Linux programs that does require 64bit newlib or clib functions.

Ctorrent for exsample

Changing such software to use the 64 bit C library functions wont be much easier than changing it to use the 64 bit dos.library functions, which you can do already with the last public SDK.

Topic | Forum

joerg

Re: Workbench enhancement project

Posted on: 2008/7/2 23:53 #1295

Just can't stay away

@Hans

Quote:

So what's missing is enforcement of the permissions at the OS level (shouldn't the filesystem be involved in this too?), and multi-user support in the sense of having the option to log in, and per-user environments.

The file systems must not be involved, they have to do way too much already which should be in dos.library instead of having to duplicate it in each file system, for example notifications had to supported by the file systems themself. At least half of the code of most AmigaOS file systems has nothing to do with the file system but are just support functions which are the same in all file systems and should be in dos.library instead.

Quote:

Per-user environments would probably be pretty easy to do; enforcing access restrictions would require API level changes.

No API changes are required, except for one new function to change the owner of a task/process (of course only if the current owner is the superuser), and maybe some other settings like an umask.

Topic | Forum

joerg

Re: Workbench enhancement project

Posted on: 2008/7/2 23:35 #1296

Just can't stay away

@Rogue

Quote:

You could of course make e.g the DOS Open call respect ownership. It would be some effort, but not undoable.

Only little changes are required, but in lot's of places in dos.library, and small exec changes (not only dos processes but exec tasks need an owner, exec task can't do much I/O, but they can create dos processes which have to have the same owner as their parent task).
It was done alreay on AmigaOS in multiuser, by patching some exec and lots of dos functions.

Quote:

You will still have issues. For example, people could use packet-level I/O to access the file system. That would need to be changed.

It's no problem to block all packet-level I/O in a file system if they are done using exec/PutMsg() instead of dos/DoPkt() or dos/SendPkt(), and the dos.library packet functions just have to check the permissions like all other dos functions.

Quote:

Also, since there is no memory protection, it would be relatively easy to kill this method and gain access.

Of course, just like with the old multiuser/MuFS where all you had to do was to change the boot block file system ID back to the FFS one to get full access to all files on a "protected" MuFS partition. It wont be a secure system, but it's enough for supporting multiple users/logins where one user can't access or even delete the files of the other users by accident.

Topic | Forum

joerg

Re: Workbench enhancement project

Posted on: 2008/7/2 18:57 #1297

Just can't stay away

@TSK

Quote:

@thread
Quote:
multiuser

Are there any news of that rumoured new filesystem for OS4 ? Or was it completely false rumour ?

There is nothing multiuser related a file system can change, FFS2 and SFS support UID, GID and the group/other protection bits as well, there is just nothing in AmigaOS which uses them. You can set the owner and group/other protection bits with the commands in C: and display them with "C:List groups", but they are ignored.
ixemul.library uses them, FTP and HTTP servers should as well, but AmigaOS itself doesn't.

Topic | Forum

joerg

Re: Workbench enhancement project

Posted on: 2008/7/1 19:06 #1298

Just can't stay away

@abalaban

Quote:

- PartionWizard : better SFS support

What's wrong with it?

Quote:

- File systems : FAT32, NTFS

FAT32 is supported already by CrossDOSFileSystem.

Quote:

- AISS yes I agree totally, it must be integrated in the OS, but it would be good to have a way of caching in order to prevent applications spend ages to launch...

There is an image cache in intuition which is used by the ReAction classes. Unless you have TBImages: on an extremely slow file system like FAT or FFS even the time it takes to load the images for the first time shouldn't be noticeable.

Topic | Forum

joerg

Re: Jagged Alliance 2 Tester needed

Posted on: 2008/6/27 16:48 #1299

Just can't stay away

@ToAks

Quote:

Are you 100% sure that the CAB extrator i ported won't work?

If it's just a standard CAB archive you don't need any tools, XAD, and therefore SYS:Utilities/UnArc, can extract CAB archives.

Using the UnZip and UnArj tools for the Descent II installation wouldn't have been required either, XAD/UnArc supports these 2 archive types as well.

Topic | Forum

joerg

Re: OSD in OS4?

Posted on: 2008/6/24 1:28 #1300

Just can't stay away

@Jack

Quote:

Edit2:
What about sprite idea?
To draw into a bitmap and pass it as sprite....

On most gfx cards there is only a single sprite, i.e. you'd have to replace the mouse pointer, it's way too small to display any readable text in it and has only 2 colours.

Topic | Forum

Top

« 1 ... 62 63 64 (65) 66 67 68 ... 86 »