On 14Dec04:2238-0500, s...@9front.org wrote:
> Aren't they talking about rc when running on their operating system?
Certainly. It serves as a textbook example of inadequate
software porting due to insufficient understanding of the
differences between the source and target environments.
Once the
I started on my ESX (3.5i) platform, but that installs on SCSI drives
and I assume that these are not configured in the 9atom.iso image.
So I tried my fanciest (newest) motherboard, with a 500GB SATA drive.
Booting off USB suggests that the SATA controller is not recognised.
The PCI identification
> So I tried my fanciest (newest) motherboard, with a 500GB SATA drive.
> Booting off USB suggests that the SATA controller is not recognised.
> The PCI identification is Vendor 8086 (Intel) and, for some reason I
> can't fathom, device 27df or 27c0. The latter seems to require IRQ 11
> (I only gl
Steve... LOVE IT!
BTW, which "virtual file" system did you use on embedded Linux? LIBIXP?
On Thu, Dec 4, 2014 at 10:35 AM, Quintile wrote:
> I looked at dbus for an embedded Linux project at work a few years ago, I
> ran screaming.
>
> I convinced them to use an ascii protocol through a virtual
> ipx?
no, fraid not. some files where generated by kernel drivers, others
where just named pipes.
> On 5 Dec 2014, at 16:59, Joseph Stewart wrote:
>
> Steve... LOVE IT!
> BTW, which "virtual file" system did you use on embedded Linux? LIBIXP?
>
>> On Thu, Dec 4, 2014 at 10:35 AM, Quintile
> i'll be happy to take a look.
Here's a serial console output while booting.
nix
pat: 0107040600070406
pmstart 0x0060 pmend 0x00012000
mmuinit: vmstart 0xf000 vmunused 0xf040
vmunmapped 0xf060 vmend 0xff
> i'll be happy to take a look.
The motherboard is ASUS P5G4IT-MK LX3, which I neglected to mention.
Lucio.
-
This email has been scanned by the MxScan Email Security System.
I'm sorry, I missed the issue somehow.
I don't see any reason to specify uname when using .u. The .u
extension favors uid. What is your usecase?
Thanks,
Lucho
On Thu, Dec 4, 2014 at 7:50 PM, Dmitry Golubovsky wrote:
> Hi
>
> Just wondering if the project https://code.google.com/p/go9p/ is
>
>> i'll be happy to take a look.
>
> The motherboard is ASUS P5G4IT-MK LX3, which I neglected to mention.
>
> Lucio.
>
>
> -
> This email has been scanned by the MxScan Email Security System.
> -
i wonder if the fix is to use something like what i did to build the timefs
example on plan9:
https://github.com/9nut/plan9/blob/master/go9p_timefs/timefs.go
essentially implement p.User, p.Group and p.Users interfaces.
On Fri, Dec 5, 2014 at 10:06 AM, Latchesar Ionkov wrote:
> I'm sorry, I mi
On 12/05/2014 01:15 PM, lu...@proxima.alt.za wrote:
I want to know who's intercepting mail that
should come directly from my desktop to the mailing list host.
-
This email has been scanned by the MxScan Email
i was going to suggest to ask the local authorities.
on the plus side, with so much transparency foisted on us, maybe the more
suspicious humans will realize that, for the most part, the rest of us are
using our one ride on the carrousel of infinite-time to do good. but
perhaps like any other addi
On Fri, 05 Dec 2014 20:15:05 +0200 lu...@proxima.alt.za wrote:
>
> Can the mailing list administrator help me figure out where the tail
> piece in this message is coming from? If the mailing list is not
> responsible (I don't see the same treatment applied to Lucho's mail,
> so I assume it isn't)
> Aren't they talking about rc when running on their operating system?
I'd still fix /tmp, myself. It does nothing but fester. Even the PDP-11 it
was a nuisance.
40 years on, you'd think someone would deal with it.
thank you for merging some of the patches on the issue tracker, latchesar. :)
Well I hope he has fun fixing a sandwich. Your words ... "because Debian
people are not very good at doing things correctly".
On 5 December 2014 at 15:14, Kurt H Maier wrote:
> Quoting Bruce Ellis :
>
> Don't these people have better things to do than finding non-bugs in
>> systems they don't
Hi
Thanks to everybody who answered. I posted another comment to the issue 34
https://code.google.com/p/go9p/issues/detail?id=34#c2
where explained the use case and provided the diagnostics for the problem.
Briefly, the problem is: when using 9p kernel mounts in Linux over a
domain socket, a 9p
The 9p server gets valid uid, the Linux kernel sends separate Tattach
messages for each user that accesses the server. The issue with remote
systems having different uids is no different than any other remote file
system in Linux. As somebody already mentioned, your patch isn't very
clean, so I am
> Below I've copied headers from your email.
I have two Internet access providers, I'd like to compare paths
through each. Mind you, the right idea is to bounce all my mail
through my Cape Town server, it is a hosted physical device that I
trust (mostly) to have unshaped access to the Internet.
> i was going to suggest to ask the local authorities.
They are the ones I hold responsible. It starts as an attempt at
minimising impact and it always transforms into an effort to maximise
profit. The transformation is from communal good to personal greed.
Always.
For some reason, personal gre
> Even if there was a way to pass desired numeric UID to a 9p server,
You're glibly using a single concept, 9P, to describe two not entirely
compatible entities, the Unix and Plan 9 implementations.
Unfortunately, this confuses the issue and I, for one, can't
understand from your description, whic
> It is what it is. Not worth spending your time learning the
> details of email related RFCs and how they are used & misused.
> Instead write a nice useful 9p filesystem!
I could not agree more. But I've caught up with RFC 5322 recently: my
current project (I am getting paid a nominal amount to
> I'd still fix /tmp, myself. It does nothing but fester. Even the PDP-11 it
> was a nuisance.
> 40 years on, you'd think someone would deal with it.
Are you being intentionally ambiguous, Charles? /tmp/ in Unix (my
guess) or /tmp/ in Plan 9 (quantum forbid!) as Unix aficionados may
choose to int
23 matches
Mail list logo
