Re: A niche for the Hurd - next step: reality check

[Arne Babenhauserheide]

Am Mittwoch 29 Oktober 2008 12:16:58 schrieb [EMAIL PROTECTED]:
> > - All-in-one out-of-the-box distro running a webserver for crash-proof
> > operation.
>
> I don't really see any advantages the Hurd would offer for ordinary
> software appliances compared to other systems. The whole point of the
> Hurd is giving more power to the users, and software appliances are
> precisely about needing as little intervention as possible...
>
> However, I dwelt on an interesting variation above: For *virtual*
> appliances the Hurd might be interesting -- using hurdish
> subenvironments instead of full virtualisation, they could be more
> efficient and convenient.

Maybe it could have an advantage by running several different unpriviledged 
webservers, where users can also test somewhat insecure technology without 
endangering the whole system -> lightweight virtualization. 

For example using one subenvironment per site. 

On the long run (via improved resource management) this could offer the 
distinct advantage that overloading one site won't bother the others too much. 

For example my sites MySQL accesses once overloaded my providers server (I had 
too long logging enabled and got a traffic spike). They transfered my site to 
a different server to keep the other sites in operation (and wrecked my 
database in that process - I had to painfully recover one of the sites via 
archive.org...). 

On a box with advanced resource management, this wouldn't have affected the 
other sites too much. 

There it might even be possible to add free accounts with unguaranteed service 
(when other sites need the power, the free sites get slowed down 
automatically). 

Best wishes, 
Arne

-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt


signature.asc
Description: This is a digitally signed message part.

Re: A niche for the Hurd - multi-core systems

[Arne Babenhauserheide]

Am Dienstag 21 Oktober 2008 09:44:40 schrieb Samuel Thibault:
> Matthew Ayres, le Mon 20 Oct 2008 17:59:37 +0100, a écrit :
> > I would like to see the Hurd focusing on multi-core systems.
>
> Mach would need to be SMP-fixed first :)

Does that mean the Hurd can't yet be used on multi-core systems? 

Best wishes, 
Arne

-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt


signature.asc
Description: This is a digitally signed message part.

Niche for the Hurd - summary 2 - niches sorted according to necessary work

[Arne Babenhauserheide]

Hi, 

I sorted the niches according to the amount of work necessary to get 
into them. 

Please comment (even if it's only a short sentence to one of the 
niches)! 

The interesting part is, that I didn't find any unfeasible idea... 

- 
http://www.bddebian.com/~wiki/community/weblogs/ArneBab/niches_for_the_hurd/

Reality check
-

Check which of the ideas can already be done easily with the Hurd in 
its current state, which ones are a bit more complex but already 
possible, which ones need a bit of coding (could be accomplished in a 
few months judging from the current speed of development), which 
ones need a lot of work (or fundamental changes) and which ones 
aren't possible. 


### Already possible and easy

- Sample translators: 
* hello world. 
* transparently bind FTP into the filesystem
* hostmux + ftpfs -> connect to FTP automatically via asking for a 
dir named after the hostname -> fully transparent FTP filesystem: 
"touch ftp: ; settrans ftp: /hurd/hostmux /hurd/ftpfs / "
* bind any filesystem at any place in the filesystem (you have 
access to) without needing to be root. 
* elegantly mount iso images and similar as unprivileged user. 

- Other useful stuff: 
* Install deb-packages from an ftp server via 'dpkg -iO 
ftp://foo/bar/*.deb'

- Having a complete GNU System (but not yet on every hardware, and 
only about half the software Debian offers has been ported). 


### Already possible but complex or underdocumented

- Easier access to low-level functions via translators. 

- Operating system study purposes as it's done with minix. 

- Tinkering for fun - need documentation about the fun things which 
can be done. 


### Need a few months of coding

- A filesystem-based package manager. 

- A framework for confining individual applications is really just one
possible use case of the hurdish subenvironments. Writing the tools
necessary for that should be quite doable in a few months. It's probably
not really much coding -- most of the work would be figuring out how it
should be set up exactly. 

- Running parts of the Hurd on different computers, maybe even with 
shared servers on dedicated hardware (Cloud Computing when the 
servers can be made to migrate from between computers). Maybe this 
should be placed in "need a lot of coding". 

- subhurds for quickly adapting the whole system without bothering 
others. 

- Define your personal environment via translators, so you can easily 
take it with you (translators written in scripting laguages can make this 
easier - they could also for example be taken to each computer on 
USB stick). 

- A more powerful alternative to FUSE filesystems: While FUSE is 
limited to standard filesystem semantics, while Hurd translators can 
implement whatever they want.
It is possible to change the behaviour in any aspect, including the way
file name lookup works. Admittedly the only specific use case I know is
the possibility to implement namespace-based translator selection with 
a set of normal translators, without any changes to the Hurd itself.
It is also possible to extend the filesystem interfaces, adding new 
RPCs and options as needed. This allows using the filesystem for
communication, yet implementing domain-specific interfaces where
standard filesystems are too unefficient or cumbersome. A sound 
server would be one possible use case. 

- Namespace based translator selection (if you for example want to 
quickly check the contents of an iso image, just look at them via 'ls 
image.iso,,iso9660fs'). 


### Need a lot of coding or fundamental changes

- Effective resource management (For example via Viengoos on which 
Neal Walfield is working). The idea is that we could make a virtue out 
of necessity: Once we have a proper resource management 
framework, we should be able not only to catch up with traditional 
systems in this reagard, but in fact surpass them.

- The possibility to create more efficient and powerful desktop 
environments. 

- Multicore systems (need to fixup Mach for SMP)

- Currently to offer CPU time to some project (like the World 
Community Grid), it is necessary to install a program from them, and 
they can then do only what that proram allows them to - which leads to 
reinventing a processing environment instead of just using the existing 
OS. 
With the Hurd people could just create a user for them, give that user 
specific permissions (like "you're always lowest priority"), add the 
public ssh keys of the project they want to donate CPU cycles to, and 
the project could just turn the computer into the environment it needs 
for the specific computation, without compromising the main system in 
any way.

- A shared MMORPG game world consisting simply of files for levels 
and person descriptions with access rights. All synchronizing is done 
on the translator level. Programs only have to display the given files 
and quickly update the state of their own files, so the programs

Re: A niche for the Hurd - dpkg -iO ftp://foo/bar/*.deb

[Arne Babenhauserheide]

Am Sonntag 02 November 2008 01:23:15 schrieb Samuel Thibault:
> Arne Babenhauserheide, le Sun 02 Nov 2008 01:03:47 +0100, a écrit :
> > Am Montag 20 Oktober 2008 15:00:22 schrieb Samuel Thibault:
> > > - Nice features: dpkg -iO ftp://foo/bar/*.deb
> >
> > Could you explain what this does?
>
> It installs (-i) the deb packages from the bar/ path of server foo, but
> only if already installed (-O).  Quite useful to install somebody's own
> build of the hurd packages from his ftp server for instance.

Does it depend on having an FTP multiplexer setup at "ftp:", or does it work 
right out of the box? 

Best wishes, 
Arne

-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt


signature.asc
Description: This is a digitally signed message part.

Re: A niche for the Hurd - next step: reality check

[Arne Babenhauserheide]

Am Mittwoch 29 Oktober 2008 12:16:58 schrieb [EMAIL PROTECTED]:
> About the only really unique feature I'm personally aware of besides of
> the ones already mentioned, is the ability to give a user's processes
> new group permissions in a running session. I never used it so far
> however, and I wouldn't know how to use it when I need it...

How can I do that? 

Best wishes, 
Arne

-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt


signature.asc
Description: This is a digitally signed message part.

Re: A niche for the Hurd - next step: reality check

[Arne Babenhauserheide]

Am Mittwoch 29 Oktober 2008 12:16:58 schrieb [EMAIL PROTECTED]:
> I fear though that such radical things have little chance in Debian --
> so perhaps we actually need a custom distribution for that :-(

Maybe it will have a chance, when the Debian people see the advantage of it. 

And while we're convincing them, we can still just give people our own qemu 
images with all the nifty stuff activated for testing. 

We could also just offer a script which activates all the fun stuff, so debian 
doesn't have to include the fun (and a bit unconventional) stuff out of the 
box. We just have to give user a reference to our script. 

Best wishes, 
Arne

-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt


signature.asc
Description: This is a digitally signed message part.

kvm with hurd-k16.img

[Shakthi Kannan]

Hi,

I have setup bridging on the host, and running:

  qemu -boot a -hda hurd-k16.img -fda grub-0.97-i386-pc.ext2fs

boots Hurd and networking works fine as well. I am using Debian Lenny
with 2.6.26-1-686 kernel. I have installed kvm, kvm-sources and loaded
kvm-intel module as well. When I try to run:

  kvm -boot a -hda hurd-k16.img -fda grub-0.97-i386-pc.ext2fs -m 512

grub loads, it boots and stops at:

=== OUTPUT ===

...
GNU Mach 1.3.99
AT386 boot: physical memory from 0x0 to 0x1fff
unexpected ACK from keyboard

=== END ===

Why is it so? Is something else required to be used with kvm?

SK

-- 
Shakthi Kannan
http://www.shakthimaan.com

Re: kvm with hurd-k16.img

[Shakthi Kannan]

Hi,

--- On Sun, Nov 2, 2008 at 7:37 PM, Shakthi Kannan <[EMAIL PROTECTED]> wrote:
|  kvm -boot a -hda hurd-k16.img -fda grub-0.97-i386-pc.ext2fs -m 512
\--

It was reported here:
http://paste.lisp.org/display/67296

Had to use it with -no-kvm-irqchip or -no-kvm-pit.

For setting up kvm on debian, this documentation is useful:
http://kvm.qumranet.com/kvmwiki/Debian

SK

-- 
Shakthi Kannan
http://www.shakthimaan.com

Re: A niche for the Hurd - dpkg -iO ftp://foo/bar/*.deb

[Samuel Thibault]

Arne Babenhauserheide, le Sun 02 Nov 2008 10:50:09 +0100, a écrit :
> Am Sonntag 02 November 2008 01:23:15 schrieb Samuel Thibault:
> > Arne Babenhauserheide, le Sun 02 Nov 2008 01:03:47 +0100, a écrit :
> > > Am Montag 20 Oktober 2008 15:00:22 schrieb Samuel Thibault:
> > > > - Nice features: dpkg -iO ftp://foo/bar/*.deb
> > >
> > > Could you explain what this does?
> >
> > It installs (-i) the deb packages from the bar/ path of server foo, but
> > only if already installed (-O).  Quite useful to install somebody's own
> > build of the hurd packages from his ftp server for instance.
> 
> Does it depend on having an FTP multiplexer setup at "ftp:",

It does.

Samuel

Re: A niche for the Hurd - multi-core systems

[Samuel Thibault]

Arne Babenhauserheide, le Sun 02 Nov 2008 11:05:26 +0100, a écrit :
> Am Dienstag 21 Oktober 2008 09:44:40 schrieb Samuel Thibault:
> > Matthew Ayres, le Mon 20 Oct 2008 17:59:37 +0100, a écrit :
> > > I would like to see the Hurd focusing on multi-core systems.
> >
> > Mach would need to be SMP-fixed first :)
> 
> Does that mean the Hurd can't yet be used on multi-core systems? 

Hurd yes (though there are probably bugs), Mach no (as the smp code was
never maintained in the meanwhile, and IIRC the linux glue code doesn't
handle SMPness.

Note that you can still use a multi-core system, but just one core of it
:)

Samuel

Re: Niche for the Hurd - summary 2 - niches sorted according to necessary work

[Samuel Thibault]

BTW, I thought about smbfs: we'd need a servermux and sharemux there as
well, in order to be able to cd /smb://host/share/dir

Samuel

Re: kvm with hurd-k16.img

[Samuel Thibault]

Shakthi Kannan, le Sun 02 Nov 2008 19:53:05 +0530, a écrit :
> --- On Sun, Nov 2, 2008 at 7:37 PM, Shakthi Kannan <[EMAIL PROTECTED]> wrote:
> |  kvm -boot a -hda hurd-k16.img -fda grub-0.97-i386-pc.ext2fs -m 512
> \--
> 
> It was reported here:
> http://paste.lisp.org/display/67296
> 
> Had to use it with -no-kvm-irqchip or -no-kvm-pit.

And that got fixed in later revisions of kvm.
(Mach uses a pit mode that kvm wasn't emulating).

Samuel

Re: A niche for the Hurd - multi-core systems

[Matthew Ayres]

> > > > I would like to see the Hurd focusing on multi-core systems.
> > >
> > > Mach would need to be SMP-fixed first :)
> >
> > Does that mean the Hurd can't yet be used on multi-core systems?
>
> Hurd yes (though there are probably bugs), Mach no (as the smp code was
> never maintained in the meanwhile, and IIRC the linux glue code doesn't
> handle SMPness.
>
> Note that you can still use a multi-core system, but just one core of it
> :)
>

No doubt this shows my naivety, but why has GNU never built its own
replacement for Mach?

Re: A niche for the Hurd - multi-core systems

[Samuel Thibault]

Matthew Ayres, le Sun 02 Nov 2008 15:05:07 +, a écrit :
> No doubt this shows my naivety, but why has GNU never built its own
> replacement for Mach?

Just the same story: GNU used to be mostly userspace stuff. Then the
Hurd servers brought some "kernel"ness, pushing the limit a bit further.
But rewriting yet another kernel from scratch is yet another task.

Samuel

Re: A niche for the Hurd - dpkg -iO ftp://foo/bar/*.deb

[Arne Babenhauserheide]

Am Sonntag 02 November 2008 15:42:02 schrieb Samuel Thibault:
> > Does it depend on having an FTP multiplexer setup at "ftp:",
> It does.

OK. I added that requirement in the niches post. 

Thanks! 
Arne
-- 
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff 
:)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) 
Regeln.

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt


signature.asc
Description: This is a digitally signed message part.

Re: Weird O_RDWR flag definition

[Kalle Olavi Niemitalo]

Adam Tkac <[EMAIL PROTECTED]> writes:

> Yes, you could use condition like
>
> if (!((mode & O_RDWR) || (mode & O_RDONLY)))
>   die();

Better do it like this:

if ((mode & O_ACCMODE) == O_WRONLY)
die();

[bug #22861] bogus answer from pflocal to io_select SELECT_URG

[Kalle Olavi Niemitalo]

Follow-up Comment #1, bug #22861 (project hurd):

ELinks 0.12pre2 includes a workaround in set_handlers():

* Hurd bug 22861: Work around select() falsely reporting exceptions in pipes.

The workaround slows ELinks down a bit, so it may be reverted after this Hurd
bug has been fixed.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: kvm with hurd-k16.img

[Vikram Vincent]

Hello,

2008/11/2 Shakthi Kannan <[EMAIL PROTECTED]>

> Hi,
>
> --- On Sun, Nov 2, 2008 at 7:37 PM, Shakthi Kannan <[EMAIL PROTECTED]>
> wrote:
> |  kvm -boot a -hda hurd-k16.img -fda grub-0.97-i386-pc.ext2fs -m 512
> \--
>
> It was reported here:
> http://paste.lisp.org/display/67296
>
> Had to use it with -no-kvm-irqchip or -no-kvm-pit.
>
> For setting up kvm on debian, this documentation is useful:
> http://kvm.qumranet.com/kvmwiki/Debian
>
>
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498940


-- 
Vikram Vincent
+919448810822
http://swatantra.org/

Re: EQP

[Neal H. Walfield]

Hi, Jason,

> I see multiprogramming as bad as any real sense of
> time is lost and all the problems of locking and synchronization arise.

How do you deal with the following scenario:

Consider a file server: it must handle multiple simultaneous
requests; it has shared meta-data needs to be updated; and, that data
may need to be paged in.

Thanks,
Neal