Prev: [ANN] LBW 0.1: Linux Binaries on Windows
Next: IPC based on name pipe FIFO and transaction log file
From: Ian Collins on 1 Apr 2010 20:24
On 04/ 2/10 11:00 AM, David Given wrote:
> On 01/04/10 21:04, Ian Collins wrote:
> [...]
>> I find that hard to swallow. A windows VM running under VirtualBox on a
>> Linux or OpenSolaris host has minimal impact on the host. Sure it
>> pinches some RAM, but that's inexpensive these days and it will use some
>> CPU (but not a lot when idle) VirtualBox shared folders work well for
>> sharing data, but you can also run Samba/CIFS on the host. Bridged
>> networking it trivially easy to configure.
>
> Well, I have to use Windows as the host and running VirtualBox on a 4GB
> Core Duo cripples it --- it is *significantly* slower and more painful,
> in both operating systems, than in one alone. Enough so that it's
> actually unpleasant to use. (We've tried running Linux as the host and
> tunnelling the phone drivers out through Windows. Generally odd stuff
> happens and it's not reliable.)

Maybe running windows as the host is the problem? I have between 4 and
6 VMs running on one of my OpenSolaris hosts and is doesn't really
notice them. Or did you experiment with an older VB build?

PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
27709 ian 1170M 1135M sleep 59 0 27:31:19 0.8% VirtualBox/15

> VirtualBox shared folders are only okay at best. Try accessing a
> subversion repo through one and you'll find out why! (The Unix view
> VirtualBox provides of the Windows filesystem doesn't quite have the
> right semantics to keep Subversion happy. SMB has the same problem. I
> suspect it's better the other way round.)

Um, interesting. One of the tools I run in a windows VM is Tortoise
SVN. The server is on a client's site, the target drive is a shared
folder to a directory on my local development box.

--
Ian Collins
From: Ian Collins on 1 Apr 2010 20:30
On 04/ 2/10 10:09 AM, Ersek, Laszlo wrote:
> On Thu, 1 Apr 2010, David Given wrote:
>
>> I work in the embedded phone world. This means I have to deal with
>> crappy mobile phone toolchains on a regular basis.
>
> Okay, this really is starting to veer off topic, but: are most embedded
> toolchains crappy, in general? I see this complaint every week: on
> reddit, on blogs, and now here as well. One gets the impression that C
> (not C++) programming jobs are mostly available in embedded markets.
> Combine this with the "embedded -> crappy toolchain" implication... Does
> the apparent corollary actually hold?

The tools tend to appear dated compared to the current crop of host
development tools. Historically, embedded tools have been hobbled by
the connection between the target and the host. Things have improved
considerably in recent times with JTAG and Ethernet enabled targets.

There are good tools out there (Green Hills is a personal favourite) but
being proprietary, they tend to be expensive. I guess the picture is
similar to Unix tools in the 90s.

I haven't used embedded tools for development for many years. I develop
and test on my desktop and just use the target tools for target builds
and debugging the occasional (often tool related!) target only bug.

--
Ian Collins
From: Ersek, Laszlo on 1 Apr 2010 21:30
On Fri, 2 Apr 2010, Ian Collins wrote:

> On 04/ 2/10 10:09 AM, Ersek, Laszlo wrote:
>> On Thu, 1 Apr 2010, David Given wrote:
>>
>>> I work in the embedded phone world. This means I have to deal with
>>> crappy mobile phone toolchains on a regular basis.
>>
>> One gets the impression that C (not C++) programming jobs are mostly
>> available in embedded markets. Combine this with the "embedded ->
>> crappy toolchain" implication... Does the apparent corollary actually
>> hold?
>
> [snip]
>
> I haven't used embedded tools for development for many years. I develop and
> test on my desktop and just use the target tools for target builds and
> debugging the occasional (often tool related!) target only bug.

Thank you both for the answers.
lacos
From: David Given on 2 Apr 2010 07:33
On 02/04/10 01:24, Ian Collins wrote:
[...]
> Maybe running windows as the host is the problem? I have between 4 and
> 6 VMs running on one of my OpenSolaris hosts and is doesn't really
> notice them. Or did you experiment with an older VB build?

It was the most recent semi-closed-source version from the website.
*shrug* I'm quite prepared to believe that Windows is the problem, but
as I said, I have to use Windows as the host for device driver reasons.

[...]
> Um, interesting. One of the tools I run in a windows VM is Tortoise
> SVN. The server is on a client's site, the target drive is a shared
> folder to a directory on my local development box.

I *suspect* the problem is that Windows can't do atomic
rename-and-removes, which SVN uses to replace files. I believe that SVN
running natively on Windows manages it because Cygwin is emulating them,
but SVN on Linux tunnelled through VirtualBox sees the failure.

(Android builds fail miserably in the same situation, too, but that's
because they require a case-sensitive file system.

If so it ought to be easy enough to fix but I have enough to do
bug-fixing my own software than to spend time bug-fixing somebody else's...

--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "In the beginning was the word.
│ And the word was: Content-type: text/plain" --- Unknown sage
From: Måns Rullgård on 3 Apr 2010 13:02
Ian Collins <ian-news(a)hotmail.com> writes:

> On 04/ 2/10 10:09 AM, Ersek, Laszlo wrote:
>> On Thu, 1 Apr 2010, David Given wrote:
>>
>>> I work in the embedded phone world. This means I have to deal with
>>> crappy mobile phone toolchains on a regular basis.
>>
>> Okay, this really is starting to veer off topic, but: are most embedded
>> toolchains crappy, in general? I see this complaint every week: on
>> reddit, on blogs, and now here as well. One gets the impression that C
>> (not C++) programming jobs are mostly available in embedded markets.
>> Combine this with the "embedded -> crappy toolchain" implication... Does
>> the apparent corollary actually hold?
>
> The tools tend to appear dated compared to the current crop of host
> development tools. Historically, embedded tools have been hobbled by
> the connection between the target and the host. Things have improved
> considerably in recent times with JTAG and Ethernet enabled targets.

The tools supplied by the hardware vendors are invariably a huge pile
of stink. When they are based on gcc, I usually just build my own gcc
from modern sources instead. If gcc doesn't support the target,
you're obviously stuck with whatever you're given. Fortunately, most
embedded systems are ARM or MIPS, both well supported by gcc and
various commercial compilers. There is very rarely any need to stick
with the outdated junk hardware vendors give you.

> There are good tools out there (Green Hills is a personal favourite)
> but being proprietary, they tend to be expensive.

The one bug I spent the longest time (almost a week) to find was
caused by a Green Hills compiler. Since that time, I have a bit of a
distrust for them. Other compiler bugs I've found were mostly in very
obscure construct; this one was in a simple return statement.

--
M�ns Rullg�rd
mans(a)mansr.com
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: [ANN] LBW 0.1: Linux Binaries on Windows
Next: IPC based on name pipe FIFO and transaction log file