Article discussing Go, could well be D

[Daniel Gibson]

Am 20.06.2011 10:52, schrieb Johannes Pfau:
> Jacob Carlborg wrote:
>> On 2011-06-19 21:59, Jose Armando Garcia wrote:
>>> On Sun, Jun 19, 2011 at 4:19 PM, Jacob Carlborg<doob at me.com>  wrote:
>>>> On 2011-06-19 19:02, Johannes Pfau wrote:
>>>>>
>>>>> I still don't understand that completely. So does it list the files
>>>>> which will be contained in the package later, or file dependencies
>>>>> contained in other packages?
>>>>> (I'm asking because I'm not familiar
>>>>> with file-dependencies in package management systems. Most package
>>>>> management systems make a package depend on other packages, but
>>>>> not on the files in the packages)
>>>>
>>>> Ok, let me explain. When developing a package management system the
>>>> first thing one has do decide is if the package should contain
>>>> pre-built binaries/libraries, we can call these binary packages, or
>>>> the necessary files to build the package when installing, we can
>>>> call these source package (not to be confused with the source type
>>>> you've mentioned below). As a third option, one could have a mixed
>>>> package system containing both binary and source packages. Maybe
>>>> even mixed packages could be possible.
>>>
>>> Why decide on "file" package? This only works with packages that can
>>> be compiled. Think non-D source code packages and close source
>>> packages. Even one of the most commonly known "file" package manager
>>> (Gentoo's portage) allows for binary packages.
>>
>> I guess we could have a mixed system, with both source and binary
>> packages.
> 
> Definitely. Standardised source packages allow automated binary package
> building, even for different architectures. Users should also be able
> to make small changes to source packages and create their own binary
> packages easily. Source packages only wouldn't work either, think of
> users on embedded systems. Compiling everything on a machine with 16MB
> ram and 200mhz isn't fun. Also binary packages are quite convenient.
> 

1. Will you develop or compile your own software (that uses software
from the package manager) on the embedded system? I guess it's more
common to develop the software on a PC or whatever and upload it to the
embedded system.

2. Will an embedded system with such restricted resources have a x86
arch - or will it more likely be ARM or even something completely different?
Should there be binaries available for any architecture (that's hard,
because most developers probably only have x86/amd64)? If not, you'd
have to compile yourself anyway.
(And of course we need a working compiler for that architecture first)

Cheers,
- Daniel